dummzeuch

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.

OK, so Left := -(GetSystemMetrics(SM_CXSIZEFRAME) + GetSystemMetrics(SM_CXPADDEDBORDER)); works for Left (actually it's Left := Form.Monitor.WorkAreaRect.Left - (GetSystemMetrics(SM_CXSIZEFRAME) + GetSystemMetrics(SM_CXPADDEDBORDER)); because the left edge of the monitor might not be at pixel 0). It does not work for the height though: Height := Form.Monitor.WorkAreaRect.Height + 2* (GetSystemMetrics(SM_CXSIZEFRAME) + GetSystemMetrics(SM_CXPADDEDBORDER)); still leaves a gap to the bottom border of the monitor. But that's consistent with Windows + Left (but not with maximizing the window)

btw: https://devblogs.microsoft.com/oldnewthing/20150304-00/?p=44543 (I knew I read about this somewhere, just didn't remember were.)

Hm, that seems to be kind of a magical value, because if I use that rather then the -7, it works. It's also -8 on my PC.

This is not about letting the user do anything but the program positioning its window. (To allow the user to do that, the ScreenSnap property is no longer necessary in Windows 10.)

This patch was missing the changes to the .dfm file. GX_GenericUtils.GetUserApplicationDataFolder can replace the %appdata% environment variable which is what causes the dialog to fail showing the correct directory. As far as I am aware there is no official way to get that number. GExperts declares some constants depending on the VERnnn symbols in GX_VerDepConst. The public documents subdirectory is not one of them, but you could easily add a constant for that. since the required number is already part of the CompilerDefinedProductRegistryKey. Please remember that Wuppdi was only available for some Delphi versions (I don't really known which ones), so that option doesn't make sense for e.g. Delphi 6. Yes. I would implement it this way: Instead of showing the file select dialog show your own dialog. It gives the path of the wuppdi ini file in an edit field (you know the path and filename, so you can check whether it exists and display an error if it doesn't). This edit should allow drag and drop (TWinControl_ActivateDropFiles) and autocompletion (TEdit_SetAutocomplete) and offer a ... button to let the user select the file. A second edit field allows entering the name of a subfolder to import into.

Welcome to date format hell. Once you go that way, you will find out that there are many more different date formats than you ever imagined and that many of them are incompatible to each other. My favourite example: US: MM/DD/YY UK: DD/MM/YY If you have the choice always go with an international standard: ISO 8601

Assign NIL to it and later reassign the original event.

Since he already has a hex editor (looks like HxD in the screenshot), setting those bytes to zero would be easy. I don't really see the need for anything Delphi specific there at all

As far as I know they can only read from the registry. I'm also not sure when the IDE updates these entries: Whenever they change or only when closing.

I know of only one "pure pascal" solution for jpeg compression: nativejpeg

You could try to use libjpeg-turbo (or even the original libjpeg, but I don't recommend it). I don't know how do use that with TBitmap32 though, I only used it with TBitmap and a BGR-in-memory-buffer. There are Delphi interface units for it.

Bug report(s) on Sourceforge please.

general FAQ bug reports

Bug report on SourceForge please.

Some things that were obvious in the VCL apparently are not in FMX. I want to change the background color of a single control on a form, e.g. set a TEdit control which failed input validation to yellow. This must not affect the color of the other controls on the form. In the VCL I would simply set TheEdit.Color := clYellow. An FMX TEdit does not have a Color property. Instead apparently one has to use styling, controlled by the properties StyledSettings, StyleLookup and StyleName. Am I missing something? How can I accomplish this?