Daniel

Folks - why is it that hard to stay on topic? honestly, it is not hard. You just don‘t care. Feel free to create a separate thread for cross-platform development, but this topic is locked now.

Before starting a new thread about the "future of Delphi", please give some more context what exactly you would change. It would be helpful for a discussion to summarize the content of presentation and to adopt it to Delphi. There have been several threads about the "future of Delphi" and actually I am not sure, why this thread should be different or bring in any new aspects. Of course everyone of you is free to create a new thread - but you should take a moment to check, if it's really a value for the community of if it's just a recapitulation of existing threads.

Peter come on - as you can read in the previous answers there is no need to write to EMBT. And this is the wrong thread to discuss about the things that Delphi may be suffering from.

Nonetheless - your question is answered.

This topic is about a 3rd-party welcome-page, please discuss the live-bindings in a separate topic.

Not being a MVP anymore, it is the first time in years that I do not have access to a recent version Delphi. But I will have a solution for you. Please give me a couple of days.

Done, thanks for the reminder.

*sigh* i see no reasons for getting personal. There are different ways to look at and to solve a problem.

Hi, next time please chose a more specific subject for your question. 😉

In short: We try to respect the intentions of Embarcadero. And their intentions are quite clear - they want the users to use either GetIt or their download-portal located at my.embarcadero.com. But some patches for very ancient versions of Delphi (version 6 for example) are floating around the internet. And although their copyright is still clearly defined - it is not "public domain" - Embarcadero considered it the lesser of two evils if customers were helped with a direct link.

About the discussion of deep-links: Indeed they are not welcome. Embarcadero has its download-portals and can make the files available there. The fact that the files can be downloaded without further protection does not mean that we will publish these links here as long as there are official sources for them.

Account was deleted on request. But in general we do not discuss things like this in public. I will close this topic now.

Hi, just click the "follow"-box in the upper right. I admit, that this one is not easy to be recognised as a button, but it has some power...

I have removed some offtopic-rants. Please stay focused on topic.

*sigh* I am fighting with a function from a DLL requiring a pointer that is dereferenced twice. In theory it should be "a pointer to a pointer to a pointer" but somehow I did not find the right language-contruct in Delphi. I actually have to deal with two functions: one to acquire a data-structure, one to release it. while I found a way to get my hands on the correct data (so the first step of acquiring the data seems to be working), my program crashes when I try to free that memory. Basically it is the following: typedef struct libvlc_media_track_t { /* some fields */ } libvlc_media_track_t; /* the two functions I need to import */ unsigned libvlc_media_tracks_get( libvlc_media_t *p_md, libvlc_media_track_t ***tracks ) // the second param is the problematic one libvlc_media_tracks_release( libvlc_media_track_t **p_tracks, unsigned i_count ) The import-declaration of the functions look like this: function libvlc_media_tracks_get(p_md : libvlc_media_t_ptr; var tracks : Pointer) : LongWord; cdecl; procedure libvlc_media_tracks_release(tracks : Pointer; i_count : LongWord ); cdecl; These declarations are not from me, but - so far - all other declarations from that unit have been working correctly, so I assume that these are also correct. My approach was to offer just a pointer to the first function and do some nasty type-conversions afterwards: var LTracksPtr : Pointer; LTracks : libvlc_media_track_t; // a record LCount : int32; begin LCount := libvlc_media_tracks_get( FVLCMIntf, LTracksPtr ); // FVLCMIntf is just (an initialised) pointer LTracks := libvlc_media_track_t( Pointer(LTracksPtr^)^ ); // works (i have the correct data in the record), but looks ugly to me libvlc_media_tracks_release( Pointer(LTracksPtr^), LCount ); // does clearly not work Now the effects are more or less funny - after trying to release that memory in one out of two cases a listview in my program vanishes. Looks like it has a very unfortunate memory-address that is referenced here by mistake. Could anyone with more c-experience point me into the right direction how to deal with that functions?

I agree with @pyscripter, please come back to the topic.

Good catch - but the is a reduced code-sample. Same situation still applies when comparing values from an array with values that are generated at runtime.

The original cry for help reached me from a developer using 10.3.x - so this is not limited to 10.4.2.

I am sorry to hear this. I also wish you a fast and full recovery.

We now have six pages of first impressions. This topic has become, as so often with a release, a melting pot of all possible aspects. But it doesn't get any better or clearer and doesn't gain any added value for someone who wants to inform himself about the new release from this page six on (probably already before). Even if it may be a "first impression" for you individually, please create a new topic for your specific question. I will leave this topic open for now so that you can quickly finish acute sub-topics.

If you want to discuss VirtualBox in detail, please use a separate topic for that. This part of the discussion seems no longer be related to Delphi 10.4.2.

Read the installation notes. The IDE itself has that requirement.

Support for DirectX11 is required by RAD Studio. This extension-pack might make this difference.

@emailx45 Could you try not to illustrate all of your posts with images? In many cases the plain information - in this case that you could not reproduce the error - might be enough and does not bloat the view of a topic.

In recent Delphi-versions the function "Windows.GetACP" does not exist anymore under this scope. The windows-scope is now called "Winapi.Windows", therefore the full-qualified function-name is now "winapi.windows.GetACP". That should compile. But - are you really sure that you don't have a toxic mixture of old and new versions from Jedi? The stuff from GetIt usually works out of the box and the errors you see there are suspicious. GetIt may have it's rough edges, but actually not this rough.