aehimself

My advise would be to branch your master and do the conversion there. That way you can cherry pick bugfix commits between them but they would be separated enough. When conversion is done simply merge/cherry pick everything back to master. If you have no version control (which you definitely should) you can start to use IFDEFs to separate code. This will make it less readable and does not allow .dfm changes though.

This was the exact approach I took to convert our legacy application to 64-bit. Our custom component package took about 2 days (plus 2 to fix issues which weren’t obvious), the program itself (1,5M loc) was only one day (plus 7 for fixing the same). I’m not saying it’s the most sophisticated method but it’s one of the easiest and definitely viable.

The pros of using window messages is you can apply the same logic to TFrame-descendants too.

I met that site a couple of times but it never managed to gain my trust for the exact reason you mentioned - a compiled DLL is an extremely unusual way to distribute your code and can do things in the background what you don’t want. “Don’t fix something which ain’t broke” applies here as well. Don’t purchase something and start to adapt all your code for it if they are working without issues.

You can discover installed Delphi versions, list their running instances (or start a new one) and instruct them to open a file via TAEDelphiVersions. This is exactly what my configurable BDSLauncher is based on, maybe that one will fit your needs without any extra coding.

Hello, Due to various reasons I'm experimenting with Delphi's TRichEdit component. I looked into the demo and quickly learned the basics but I didn't find any way to insert a picture. My searches lead to two solutions: - LINK. With a RichOle.pas file create an object from the image and insert it into the RichEdit using OLE. This method worked, but it embeds it instead of inserting (image is not shown, only an icon and the file name. Picture opens correctly when double-clicked) - LINK. Load the bitmap and convert it into rich edit compatible code. Insert this code using EM_STREAMIN. This method did absolutely nothing Another way (which probably works) is to copy the picture to the clipboard and paste it's contents into the RichEdit but this just feels way too hacky. The question is, how to insert a picture in a TRichEdit the most elegant way? I'm attempting on Delphi 10.4.1 / 10.4.2 / 11.1. Thanks!

I wish this was explained further. Maybe we will finally get TZipFile.Delete / TZipFile.Remove? 😄

Hah, I didn't even know this feature existed 😄

By locking you mean they cannot be interacted with? If yes, just write a recursive method to walk through your form, disabling / enabling your controls in the process: Procedure TForm3.LockControls(Const inLockControls: Boolean; inParent: TWinControl = nil); Var a: Integer; Begin If Not Assigned(inParent) Then inParent := Self; For a := 0 To inParent.ControlCount - 1 Do Begin inParent.Controls[a].Enabled := Not inLockControls; If inParent.Controls[a] Is TWinControl Then LockControls(inLockControls, inParent.Controls[a] As TWinControl); End; End;

A little too late, but TSplitView shipped with D11 can also do this, with an addition of animated opening / closing. The backdraw is it only can be opened to the side, so you cannot expand down as far as I checked. I'm using it as a collapsible menu, opening by hovering your mouse on the chevron:

I really don't see the issue here. Pipe delimitation is not common; either search-replace with tabs and use any available database manager or write your own. Use FireDAC, Zeos or any SQLite.dll wrapper directly to "connect" to your database. If you choose a component-based approach you can load the contents in some kind of TDataSet-descendant and you can manipulate records as your heart desires.

I am using Delphi exclusively but I suppose it'll be similar in CB too. Forget about ProcessMessages. If you really need, you can call Button1.Repaint for example. This will skip the message queue and simply "force" the control to refresh it's appearance.

I found the meme about it:

A ComboBox suffers from the same 2-click issue and while it does save space, still not the usual way to handle these inputs. If UI space is an issue you should be looking at how to increase the space, not on workarounds. Unfortunately at work people were doing something similar and just pulled things closer together when they ran out of UI space (or the infamous pagecontrols on tabsheets). The end result physically hurts to look at.

I advise against the use of TCheckBox or similar for such an input. There are multiple reasons: "greyed" state doesn't clearly mean "not sure" AND you might have to click twice to change your answer from one answer to the other. I'd suggest to have three radio buttons, right next to each other, with each column having a title; like an online questionare. Somthing like this:

If you are sure you can not put the component in sync mode somehow, what you can do is: - Create a thread, have a private boolean called "_requestcompleted" - Create the component in the thread's context - Set the event handlers, flip _requestcompleted to True in the handler when... well, the request is completed - in the thread's context, send the request and then have a loop like... Repeat // Message pump, if needed for the component Sleep(100); Until _requestcompleted Or Self.Terminated; This method is inefficient as the CPU is spinning in a loop but at least easy to understand. If your component needs no message pump, you can switch to events and use WaitForMultipleObjects for a more resource-friendly approach.

You are talking about two completely different areas with completely different functionality. A component is displaying / allowing to change a value, The source of said value is the dataset, which can behave in multiple different ways... either send the data to it's connection, use CachedUpdates or simply Cancel and revert to the unchanged state. The connection will be the one deciding when the data will be written to the database by further caching and transactions. You don't want to mix the functionality, especially if that functionality already exists. Spend that free time further improving your component, to display and change a value only 🙂

I see. Thank you for confirming.

Isn’t the dropdown menu a TPopupMenu? Or you mean in this scenario the property is not populated?

Not sure if it will work here but you can try to check the TPopupMenu.PopupComponent property.

Zeos recently implemented a Proxy driver which does exactly what you describe - it only exposes the proxy and client apps “connect” to this proxy. It supports all protocols which Zeos itself supports. I personally never tried it so I cannot say anything about security and such, but you can give it a try.

This is a clustermess. If you are publishing to Android you must have an update subscription so you can continue to be present; but even if you do you’ll do it on a beta platform which might not produce fully functioning code…? Am I getting it right…? Fortunately I’m not affected it; it just sounds extremely strange. I did not check the article but I’m sure the steps needed could be automatized and depleted via a patch.

Is this shortcut to the exe what Delphi compiles? Windows Explorer caches the icon of executables and shortcuts so you might need to clear that cache for you to see the icon you just set.

According to the stack trace it is indeed GDI object exhaustion. Check where and how you are manipulating images and make sure you are disposing of them properly. We had this when there was an image list on a frame which was created thousands of times. Moving the imagelist to a common place solved our issue immediately. @Dalija Prasnikar we also received EOutOfResources when our application used up all available user handles so it’s not strictly GDI-related. But yes, leaking handles often pop up as Delphi classes in the memory leak report.

Yes, it should be ListView1.Items.Add. If you declared your class like I posted (descending from “nothing” = TObject) it does not require an owner (not a parent). If the definition is correct, it’s still possible that the RTL has a component named TListItemData, so you can try to name yours “TMyListItemData” or something else - that will help the compiler to recognize which one you want to create and what parameters it requires.