Uwe Raabe

Install PngComponents - it registers the old format per default.

Filing a feature request may be helpful.

Recent Delphi versions also allow this construct: function GenerateAppGUID: TGuid; begin Result := TGUID.Create('{481E85E5-3874-4FCB-BEA1-B65D640AE6D3}'); end;

Well, Code Coverage can also tell you which parts of a tested method was left out and thus needs more tests. OK, not that much helpful when you don't do tests. It is not meant to be executed in the customers production use, there you are right. That is more what collecting the areas actually used are for.

Open MMX Code Explorer properties and navigate to the History page. Under Drop Bookmarks set Before modifying source drop bookmark on cursor position to none.

In Project Options - Building - Build Events select All configurations - Windows 32-bit platform. Then in Post-build events set Commands to ren $(OUTPUTPATH) $(OUTPUTNAME)32$(OUTPUTEXT) Note, that you won't be able to debug that.

What are you trying to achieve?

In SOFTWARE\Embarcadero\BDS the BDS part can be changed with the -r command line switch. On the other hand, nit all sub keys of SOFTWARE\Embarcadero belong to valid Delphi installations, so it needs some more heuristic to find them.

I suggest to make the BDS part of IDERootKey as an additional parameter to cover the case where the IDE is started with the -r option. A welcomed extension would also be to find all these sub keys for given or all Delphi versions.

The false part of this car analogy is that the car is not FREE, you are only allowed to drive it for one year without paying for it. At the end even that analogy is false right from the beginning as it is rather difficult to find someone letting you drive its car for free - at least not for one year. It would also be a bit tricky to get some extras installed to that car - all for free. All this confirms my conviction that any car analogy used for software issues can only be fundamentally flawed.

I beg to disagree here. If it is seen as an invalid construct the compiler should complain. As long as the compiler is fine with such a construct, there are only implementation details in Object Inspector responsible for the crash. There is nothing except missing developer time that should prevent to fix those. We can argue about the priority, though.

Strictly speaking it is TOnChange(ASender: TCustomEdit<Integer>; AValue: Integer), but I suspect a general lack of OI support for that. You should file a QP report for that.

Just a guess, but I suspect the Object Inspector cannot cope with the generic event.

AFAIK that is not possible. It is hard-coded in delphicoreide<xxx>.bpl

Of course I do, but that cannot be fully described in a few sentences of an answer to your question. F.i. it took more than two hours to explain only the basics to a co-worker and we had to make a cut as it was too much information to grasp all at once. After all I developed that in several weeks (if not months) to get all things running fast and stable. I also don't know if what is working for us will work for your use case. My plans are to do a more detailed blog post on this, but as that is going to target a broader audience the examples given will probably fall in the incrementing integers category, too.

Be aware that this also needs a dedicated TRestClient for exclusive use in the internal thread. Also make sure that the TRestRequest events are either thread-safe or the SynchronizeEvents property is set to true. For create the TRestRequest dynamically for each case and create the TRestClient with the request as owner. That way the client is automatically freed with the request.

You have to create an isolated set of all components for each thread.

You cannot do that even for a regular variable. It works if you declare a constant first and use that one for the assignment. That even works for the inline var.

At least his profile shows 10.2 - but nevertheless, it doesn't work always in 10.4.2 either (as many LSP backed features don't). So the QP entry should rather be a bug report than a feature request.

You can't put attributes on code not under your control (like the VCL f.i.).

Add an OnDrawItem or OnAdvancedDrawItem event handler to these menu items with something like the following code: ACanvas.Font.Style := [TFontStyle.fsBold]; ACanvas.TextRect(ARect, 1, 1, StripHotkey((Sender as TMenuItem).Caption)); As obviously styles are involved, you might have to take that into account, too.

"Use constants" the boss told us: const cDecimals0 = 0; cDecimals1 = 1; cDecimals2 = 2; cDecimals3 = 3; cDecimals4 = 4; cDecimals5 = 5; cDecimals6 = 6; cDecimals7 = 7; cDecimals8 = 8; cDecimals9 = 9; cDecimals10 = 10; cDigits0 = 0; cDigits1 = 1; cDigits2 = 2; cDigits3 = 3; cDigits4 = 4; cDigits5 = 5; cDigits6 = 6; cDigits7 = 7; cDigits8 = 8; cDigits9 = 9; cDigits10 = 10; cDigits11 = 11; cDigits12 = 12; cDigits13 = 13; cDigits14 = 14; cDigits15 = 15; cDigits16 = 16; cDigits17 = 17; cDigits18 = 18; cDigits19 = 19; cDigits20 = 20; cDigits21 = 21; cDigits22 = 22; cDigits23 = 23; cDigits24 = 24; cDigits25 = 25; cDigits26 = 26; cDigits27 = 27; cDigits28 = 28; cDigits29 = 29; cDigits30 = 30; cDigits31 = 31; cDigits32 = 32; cDigits33 = 33; cDigits34 = 34; cDigits35 = 35; cDigits36 = 36; cDigits37 = 37; cDigits38 = 38; cDigits39 = 39; cDigits40 = 40; cEndPos0 = 0; cEndPos1 = 1; cEndPos2 = 2; cEndPos3 = 3; cEndPos4 = 4; cEndPos5 = 5; cEndPos6 = 6; cEndPos7 = 7; cEndPos8 = 8; cEndPos9 = 9; <snip...> cEndPos997 = 997; cEndPos998 = 998; cEndPos999 = 999; cEndPos1000 = 1000; cEndPos9000 = 9000; cIndex0 = 0; cIndex1 = 1; cIndex2 = 2; cIndex3 = 3; cIndex4 = 4; cIndex5 = 5; cIndex6 = 6; cIndex7 = 7; cIndex8 = 8; cIndex9 = 9; cIndex10 = 10; cIndex11 = 11; cIndex12 = 12; cLength1 = 1; cLength2 = 2; cLength3 = 3; cLength4 = 4; cLength5 = 5; cLength6 = 6; cLength7 = 7; cLength8 = 8; cLength9 = 9; cLength10 = 10; cLength11 = 11; cLength12 = 12; cLength13 = 13; cLength14 = 14; cLength15 = 15; cLength50 = 50; cLength102 = 102; cLength117 = 117; cLength298 = 298; cLength618 = 618; cLength800 = 800; cStartPos0 = 0; cStartPos1 = 1; cStartPos2 = 2; cStartPos3 = 3; cStartPos4 = 4; cStartPos5 = 5; cStartPos6 = 6; cStartPos7 = 7; cStartPos8 = 8; cStartPos9 = 9; <snip...> cStartPos995 = 995; cStartPos996 = 996; cStartPos997 = 997; cStartPos998 = 998; cStartPos999 = 999; cStartPos1000 = 1000;

Might be tricky to persuade the third party lib to create your new classes rather than its own.

I'm probably going to regret it, but I'll throw this one into the discussion: function BlankControl(EditControl: TObject; const EditMess: string; ShowErrorMsg: Boolean; MaxLen: Integer): Boolean; begin Result := False; try if EditControl is TCustomEdit then Exit(length(trim((EditControl as TCustomEdit).Text)) < MaxLen); if EditControl is TComboBox then Exit(length(trim((EditControl as TComboBox).Text)) < MaxLen); if EditControl is TDBComboBox then Exit(length(trim((EditControl as TDBComboBox).Text)) < MaxLen); if EditControl is TDBRadioGroup then Exit((EditControl as TDBRadioGroup).Value = ''); if EditControl is TDBLookupComboBox then Exit((EditControl as TDBLookupComboBox).Text = ''); if EditControl is TDBCheckBox then Exit((EditControl as TDBCheckBox).State = cbGrayed); finally if Result then Showerror(EditControl, EditMess, false, ShowErrorMsg); end; end;

Ehm! That Exit call will only exit procedure gotoTrue, but not function BlankControl. Funny, that such a suggested improvement perfectly qualifies for the reason of this thread