Anders Melander

Yes. It doesn't hurt but if you are not referencing the type then you might as well delete it. I couldn't spot any obvious issues after a brief look through the source. One thing I would do though, is to move the TCommPortDriver.Create into the Execute method so it is constructed in the context of the thread, instead of the calling thread (which is supposedly the main thread).

So use an installer or zip the files. I'm not buying the argument that users can't figure out how to unzip a file or run an installer. IME, they can if they have to.

Yes it is because it trashes the page cache. If memory is low then something else has to be paged out before the exe can be extracted to memory - and then paged out.

CommPortReceiveData is a method pointer. @CommPortReceiveData is a pointer to a method pointer. You have declared TCommPortReceiveData as a "procedure of object". That makes it a method pointer so this: procedure CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); is wrong (it's not a method; It's a procedure) while this: procedure TUploadThread.CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); is correct. You haven't declared the method. You have declared a pointer to a method. Your declaration in TUploadThread should look like this instead: TUploadThread = class(TThread) private ...other stuff... procedure CommPortReceiveData(Sender: TObject; DataPtr: Pointer; DataSize: Cardinal); ...more stuff... end;

I wouldn't know; I'm not confused - but that shouldn't stop people from explaining if they find joy in that. It should have been obvious that I know recent Delphi versions doesn't support being installed on Windows 7, given that I've installed and run several versions on Windows 7 and of course got told by the installer that it wasn't supported. I also stated that I hadn't encountered any problem with Delphi applications running on Windows 7.

And it shouldn't; It is functionality that belongs in another layer. Keep it simple.

Trace Into = Step Into But you don't need to trace into. You can just place a breakpoint inside your square function. This is a very simple problem so I suggest you try to single-step through it "in your head" first; What happens when you call square(0), square(1), etc.

Thanks for clearing that up - or not.

Okay, but it seems it doesn't. At least I haven't encountered anything in it that did.

I don't think that list is up to date given that Delphi has complained when you tried to install it on Windows 7 since 10.3 (AFAIR). That said, I upgraded my main system from Windows 7 to 10 last year but before then I didn't have any problems with the IDE or applications not working on Win7.

Btw, you should let the TSizeableLabel own the HostedLabel so this: HostedLabel := TLabel.Create(AOwner); should be: HostedLabel := TLabel.Create(Self); - And there you have an example of when to use Self. Now since the HostedLabel is owned by the control, it will be destroyed automatically when the control is destroyed (the base class TComponent takes care of that), so you can must get rid of the HostedLabel.Free.

If you search here for "Style guide" I think you can find some good ones. Be aware though that most of them will pretend to teach the One True Style and that is obviously false because I haven't published it yet 😉 TCustomControl is probably the easiest to work with. You'll be using a window handle per handle so it's not super optimal, but I wouldn't worry about it unless you'll be using hundreds of these at the same time. With the handles as separate controls you should also be able to generalize your control so it can attach itself to any TControl instead of embedding it (like I what I thought you were doing - good thing I didn't delete the comment 🙂 ).

Very nice! Here's some suggestions from looking through the code: The default scope is published so you'll probably want to start your class declaration with private scope: TSizeableLabel = class(TCustomControl) private ... By convention member variables are prefixed with F (for field). private FInSizingHandle: boolean; FResizeInProgress: boolean; FMoveInProgress: boolean; ... The HostedLabel should be a property, with a setter, not a variable (reason comes below): private FHostedLabel: TLabel; procedure SetHostedLabel(Value: TLabel); public property HostedLabel: TLabel read FHostedLabel write SetHostedLabel; ... procedure TSizeableLabel.SetHostedLabel(Value: TLabel); begin if (Value = FHostedLabel) then exit; FHostedLabel := Value; end; When a component links to another component, it should be able to handle that the other component is deleted. You do this by asking to be notified when the other component is deleted. protected procedure Notification(AComponent: TComponent; Operation: TOperation); override; ... procedure TSizeableLabel.Notification(AComponent: TComponent; Operation: TOperation); begin inherited; if (Operation = opRemove) and (AComponent = FHostedLabel) then HostedLabel := nil; end; procedure TSizeableLabel.SetHostedLabel(Value: TLabel); begin if (Value = FHostedLabel) then exit; if (FHostedLabel <> nil) then FHostedLabel.RemoveFreeNotification(Self); FHostedLabel := Value; if (FHostedLabel <> nil) then FHostedLabel.FreeNotification(Self); end; Forget the above 🙂 I commented while I read the code and only now see that the label is owned by TSizeableLabel. In that case, the property should not have a setter. You don't need to initialize your booleans class vars to False. They have already been initialized. You don't need to test for nil before calling Free. Free already does that. You don't need to reference Self unless you need to pass a reference. The scope is Self by default. Use Pascal case: Result, False, etc. Otherwise very clean and readable code. I wish my team mates wrote code that pretty 🙂 Did you consider using 8 small controls for the handles instead? It would have made painting and the mouse and cursor handling much easier, I think.

It's not "relatively common". In my 30 years with Delphi I think I've only had a need to do it (resize a control with the mouse) once and that was for a run-time form designer. Moving a control can be done with something like 10 lines of code. Resize is harder. The Raize controls are owned by Embarcadero now and can probably be installed via GetIt. https://blogs.embarcadero.com/konopka-signature-vcl-controls-version-7/ That's not how I would do it but it's certainly a possibility. Why not try it instead of just giving up? Okay then: I googled the problem, read a lot of examples, tried some different solutions and then wrote some code based on the experience I just acquired. Worked great! Better? Fair enough. Sorry about that. I guess I just don't understand that approach to problem solving.

As far as I can see both of the searches above returns a plethora of relevant answers to your question, which you are not exactly the first to ask. So what's preventing you from using any of them?

Let me teach you a trick: https://www.google.com/search?q=delphi+move+control+runtime https://www.google.com/search?q=delphi+resize+control+runtime

So you're not using version control?

Use process explorer instead and look at the threads. It will show you the call stack which might get you some hint about what it's doing. 9 out of 10 times when the IDE hangs for me it's caused by the Structure View when the form editor is active (see above) - and the IDE never recovers. Specifically it appears to be a problem with the VirtualTreeView used by the Structure View.

I don't know where you are reading this but the sentence is assuming that the pointer points to an element in an array of integers. So incrementing the pointer will make it point to the next integer in the array. Maybe you should stay away from pointers until you figure this out 🙂

Not everything is an issue or an enhancement request. It's common to have discussions enabled so a topic can be debated before it becomes a task - if ever. It's a question of how you manage a project but if Remy prefers everything in one place then it should stay that way since the issue list is primarily a tool for the maintainers, not for the users. Personally I prefer questions and other chit-chat in the discussions. I manage a lot of different projects and I need the issue lists to only show me work items.

I would go with option 1; Get rid of the technical debt once and for all. Even if you managed to get ProfGrid working now (which is probably possible, given enough effort) you would then have to maintain it yourself going forward and since you don't have Pascal expertise this doesn't sound sustainable.

There's no design-time code in it so unless the unit is used by other design-time packages there's really no reason to do that.

Better Translation Manager https://bitbucket.org/anders_melander/better-translation-manager The Better Translation Manager (BTM) is a replacement for the Delphi Translation Manager a.k.a. the Integrated Translation Environment (ITE) and External Translation Manager (ETM). Why is it better? Well, for one thing, it's free but more important; It actually works - unlike the ITE/ETM. Why? The standard Translation Manager that ships with Delphi today was originally an individual product known as the Borland Translation Suite. With Delphi 5 it became a part of the enterprise edition. The Borland Translation Suite showed great promise but unfortunately it never evolved from its roots as an external tool and has always been hampered by severe bugs that made it completely unusable in practice. As a result nobody uses it. This can be witnessed by the plethora of homegrown and commercial alternatives. The great benefit of the standard translation system is that it just works (this is the system itself I'm talking about, not the tools. The tools suck). Apart from the requirement that you must use resourcestrings you don't need to do anything special when writing your code. At run time you just place the compiled resource modules in the same folder as your application and the Delphi Run Time Library automatically takes care of loading and using the translations based on the current Windows user interface language. Anyway, since Embarcadero has now finally admitted that they are never going to fix the Delphi Translation Manager and instead recommend that we find alternative solutions, I decided that it was time I solved this little problem once and for all. The core functionality of the Better Translation Manager was written in two weeks during my summer vacation in Italy 2019. Amazing what you can do with a little pasta! Features Does not require any changes to the source code of the application being translated. Works with the existing standard Delphi localization system. Translates resourcestrings and all strings in forms regardless of any 3rd party components used. Works on compiled application. Source code is never used. Generates localized binary resource modules (resource DLLs). Does not use an external compiler. Can import existing translations from compiled application and resource modules or from XLIFF localization source files (dfn, rcn files). Read and save TMX and TBX translation memory files. Import Translation Memory from TMX (Translation Memory eXchange), TBX (TermBase eXchange), Microsoft Glossary and CSV. Machine Translation using Translation Memory, Microsoft Translation Service or Microsoft Terminology Service. Forms, Components, Types and Values that should be ignored can be specified in a Stop List. Translations are Spell Checked. Validation Rules to catch common translation mistakes. Supports Right To Left (RTL) editing based on translation language. Translation project is stored in a single XML file. Command line interface for use in automated build systems. Fast! Refreshing a large project typically takes less than a second vs. many minutes with the ITE/ETM. Supports all Unicode versions of Delphi (i.e. Delphi 9 and later). Resource modules contain the version resource of the source application. What it doesn't do There's one task that BTM, by design, doesn't attempt to solve: Localizing the placement and size of controls. Since it has been my experience that it is a far better idea to design the user interface in such a way that the layout automatically accommodates changes in font- and text size and shorter/longer texts due to translation, I decided from the start that I would not be supporting localization of size and position of controls. This also relieved me of having to create a run time form designer, supporting 3rd party controls visually (something that nobody so far has managed to find a foolproof solution to) and deciding what individual properties constitutes size/position values. Instead I just localize all string values - and only string values. But wait... There's More! Yup, you not only get this little wonder for free. You get the full source code too. Grab it at the repository linked at top. More details at the repository. Enjoy / Anders Melander

It seems the ZZZ locales are "supplemental" or "custom" locales and that the information Windows returns about them (such as their abbreviated name (ZZZ)) depends on whether they are used by the current user or not. Wonderful! I've now added a checkbox to the Languages dialog to hide these misfits by default. There are still a few remaining ZZZ locales though that I can't explain. Hmmm. It seems LOCALE_SABBREVLANGNAME has been deprecated. It would have been nice if they had updated the documentation to reflect that little detail. https://github.com/tpn/winsdk-10/blob/master/Include/10.0.16299.0/um/WinNls.h#L750

Ah! I see what the problem is; Microsoft has changed their locale database again. They've added a bunch of weird language variants that return ZZZ as their "abbreviated language name" - among them a lot of English variants. For example, what the hell is "English (Finland)" or "English (World)" ? What exact target language did you specify? I think that if you change the target language to just "English" with no variant then the filetype should become ENU (which is actually English (United States)). You can also go into the settings and change the File naming scheme to RFC 4646.