dummzeuch

Just thought I'd mention it: Embarcadero Germany has always been very helpful when any issues arose with some strange (if not to say illegal in Germany) policies from Embarcadero. They also helped converting Named User licenses to Network Named User licenses, which is possible as long as you have got maintenance and solves the activation count issue once and for all, because you then host your licenses on premises and don't need Embarcadero's servers any more.

OK, I have apparently misunderstood the question. It is about IDE experts, not about the Experts in GExperts. Yes, these are loaded in the order they are written in the Registry. It would be possible for the Experts Manager to read all entries, delete them and then write them back in the desired order.

The main reason for me to not seriously consider Lazarus was the debugger. It sucks. Now there apparently is a new one, so I should probably give it another try.

Uwe Raabe blogged about the change regarding the TForm.OldCreateOrder property in Delphi 11: It deletes existing entries from the dfm files. While that isn't a problem if you exclusively use Delphi 11, it breaks backward compatibility with older versions. These older versions always set OldCreateOrder to False for new forms but assumed it to be True, if it doesn't exist. Once you open a form in Delphi 11 and save it, older Delphi versions will see that OldCreateOrder is missing and assume it to be True even though it was set to false before Delphi 11 removed it. That has been a major stumbling stone for keeping GExperts forms backwards compatible. I always have to check the dfms before committing them to prevent disaster as some forms were using both Create and FormCreate to initialize the forms (yes that's a bad idea) and were of course expecting Create to be finished before FormCreate was called. That was the default for all Delphi versions since at least Delphi 5. But if you set OldCreateOrder to True, this is no longer the case and bad things happened. I hope I have fixed all occurrences of this in GExperts. But actually I would like to fix this annoying behavior. Is there a way to add OldCreateOrder=False back to the dfms when the form is being saved? Simliar to removing the also annoying ExplicitXxx entries? If you have an idea how to implement this, please let me know. Mein Dank wird Dir ewig nachschleichen(*1). And I'm sure I'm not alone with that. (Literally: "My thanks will forever creep after you" but simply meaning "I'll forever be thankful to you".)

What's the problem with initializing child controls in the constructor?

IIRC the experts are created in the order in which they are registered which basically means in the order of the units in the project. And I think I "recently" changed that order to be more or less alphabetic. (for a suitable meaning of "recently") I'm not quite sure what you want to achieve. You can configure any hotkey in GExperts to your liking. I am not aware of any conflicts, if there are any (in the default configuration), please file a bug report.

They should, but only for their own code. But don't forget: They are in stalling quite a bunch of 3rd party components e.g. to support all those new fangled platforms. If Google or Apple say their SDK requires Windows 10, how can Embarcadero say, Delphi will not?

I actually still have got a Windows 8.1 installation (VM) around and I don't plan to update it to 10 ever. But that's not because I am a big fan of Windows 8, I just don't want to break a currently working environment. I'm not sure whether I want to try installing Delphi 11.2 on it though - because "working environment", you know.

Are you sure these are actual downloads? Maybe the installer treats reading from the ISO as "download".

It has been included in GExperts now. But to get it for now you will have to compile your own DLL.

Of course you could always assign a hotkey that is not yet used anywhere else. Unfortunately hotkeys have become a scarce resource and since the IDE does not provide any function to read which ones are already in use, there is no way to find out for sure. That's why I added the Editor Popup Menu expert which at least for me reduces the need for hotkeys at in GExperts. Unfortunately I also chose Ctrl+H as the default hotkey for that one, which is already taken by the Replace function of the editor. 😞

I have always wondered what determines which function of a hotkey gets precedence when there are multiple ones. I found that opening the GExperts configuration dialog and leaving it with OK makes the GExperts hotkeys take precedence for a while but not for the whole session. For editor hotkeys there is also the order of entries in the "Enhancement Modules" list of the Editor Options -> Key Mappings page. Unfortunately the help doesn't really say what effect the order has got, only that they override the hotkeys in the Key Mapping Modules listed on the left.

Did you compile the runtime package first?

I would't subscribe to that. But it definitely shouldn't be used deep inside some library (or even unit) but only in the code inside a form. So if you want to use Application.ProcessMessages from inside such a library, add some call back to the library code which is then assigned some methode in the form which calls Application.ProcessMessages. That way it's a lot less likely to bite you, because (a) you know that it's being called and (b) you can control when. And if you later decide to execute that (library) code in a secondary thread, all you have to change is the code of that callback handler.

Possibly yes. I solved it by moving all code from OnCreate events to a InitForm method and call that from the constructor (or in some cases move that code directly to the constructor). Fortunately I was never in the habit of using OnCreate at all - I prefer overriding the constructor - so GExperts was the only case where it mattered. Once I found out what the problem was, that wasn't too difficult. What I was after was some code to put into an Expert to fix this annoying behaviour of the IDE.

Yes, but unfortunately that means that if you open a form in Delphi 11, save it, and open that form in an older version of the IDE (e.g. 10.4), you will end up with a form where OldCreateOrder is True, because that's the default for this property. This can cause all kinds of bugs if you use the OnCreate event. I think that was a totally unnecessary change.

@baka0815 I would like to discuss the patch for GExperts you put on SourceForge. I think this forum is better suited for that discussion than a bug report on SourceForge. For everybody else: The patch adds a menu item to the GExperts Favorite Files expert to import the favourites from the wuppdi welcome page. It does that by reading the ini file that wuppdi uses to store its configuration. The user has to select that file and after a confirmation the entries are imported and replace the current configuration. You requested feedback, so here we go (I'll start with some problems I found and will offer some suggestions) : Your patch did not compile with Delphi 2007 (and anything older) because scoped enums were introduced at some later time. That was easy to fix by simply removing the scope. After that change it compiled and worked It created a new menu item with an associated event rather than using an action as all the other menu items on that form do. I changed that. The file select dialog does not open to %appdata%\embarcadero\bds but only puts that into the filename edit. After pressing enter that directory was shown. In my opinion it should open to the directory that is used by wuppdi in the version of the IDE it runs on, for Delphi 10.2 that would be "%appdata\emvarcadero\bds\19.0", and it should preselect wuppdiwp.ini Overwriting the existing configuration might be fine for people who have used wuppdi and never used the GExperts Favorite Files expert. Others will probably not want to overwrite their configuration, so I think the import should offer to create a folder "wuppdi" with the new entries. If somebody continues to use wuppdi he probably doesn't want to import these entries every time he changes his favourites. Maybe having an option to automatically replace the GExperst favorites with the ones from wuppdi would be a good idea. Nobody wants to maintain such lists in parallel. Alternatively GExperts could add these favorites on the fly whenever the favorites menu is opened, again replacing the GExperts favorites or adding a folder "wuppdi" to the menu. An export to wuppdi might also be a nice feature, but I don't know when wuppdi reads and writes its .ini file so the data might be overwritten. As always I appreciate any contributions to GExperts.

committed to revision #3869

Apart from restarting the IDE, File -> Favorite File Collection -> Open Default Collection also works. Yes, calling AddChildObject fixes the problem. Sorry, I missed that.

No need to fix the dialog, I already did that. Yes, the other forms work differently and should possibly be changed as well. re 5.: FavoriteFilesForm As for the root folder error: After looking at the code for switching to a different file, I think the easiest fix is to clear the tree view and call CreateFolders. But I'm not yet sure. I don't know this code well enough.

I like this a lot better but there seems to be one major problem: After importing the Wuppdi entries, it's impossible to delete the created folder. I get the error "You cannot delete the root folder, please select a different folder." I guess that's not too difficult to fix. I'll look into that later. A few things were not quite to my taste with the new dialog: It is not resizable The labels were to the left of the edit fields rather than above (which makes a possible future translation more difficult as that changes the size of the labels - but translation is not going to happen anyway). Due to 1 and 2 the input field for the filename is very small. The dialog opens centered on the monitor rather than the form There was a property and corresponding field for a reference to the Favorite Files dialog which wasn't used anywhere. I fixed these issues and once I fixed the problem with the root folder error message and did some additional tests, I'll commit it to the repository. Thanks again for your contribution.

I've got a generic TdzStreamCache implementation in my dzlib, which adds caching to any type of stream. Not sure whether it is any improvement to TMemoryStream though. I only used TMemoryStream in the unit tests to ensure that no data gets lost, I never timed it against it.

What exactly is the problem you want to solve? Reallocating memory when writing to TMemoryStream?

Pressing Win+Left will dock the current window to the left edge of the current monitor. How can do that from code? I tried to set the form bounds, in particular Left to 0 but that leaves a gap of about 7 pixels. Setting it to -7 still leaves that gap. My Google fu has left me (again). All I can find is how to use the keyboard combination for that.

That doesn't work either. If I subtract if from the top, the title bar gets partly clipped and if I add it to the height, it has no effect.