uligerhardt

Thanks, Anders! Very interesting. After reading a bit I decided it's easier to stick with my "touch" solution.

In the attached project, the internal manifest is disabled in the project options. Instead an external manifest is supplied (ExternalManifestTest.exe.manifest). Now if I compile the project and run it from explorer, the main form shows up themed as expected. If I rename the manifest and run the app again, it shows up unthemed - again as expected. Now if I restore the manifest's original name and try again, the app still appears unthemed - not expected. To make it recognize the manifest again, I have to change the date of the exe file (by recompiling or using something like "touch"). (Windows 11, Delphi XE6) Why is this and how can I change it? ExternalManifestTest.7z

Maybe you could use a file driver (I think they are/were called like that). For an example see Peter Below's StreamIO.pas, e.g. here: Text Files and Streams.

I did some threading experiments with TThread but in a more complicated situation and dropped that - I would have had to accept user input in dialogs during the thread. For my current needs handing a anonymous procedure to the thread should suffice, I think. So I'll try TThread again. Thank you all for answering to my not very well prepared question.

XE6 in the meantime (don't ask ) But still no System.Threading AFAICS.

Hi all! I have some kind of dashboard/action central that provides a host of different buttons. All of these start an independent task and display progress info about that task (in a tree view). Currently this is handled without threading, so the dashboard is blocked until the task is finished. Therefore I'd like to make these tasks into threads. What threading library would you recommend? TThread, Andreas Hausladen's AsyncCalls, OmniThread or something different?

My fragment wouldn't have compiled. And as stated I'm not sure if it helps with this: That might depend on the scenario. IIRC this syntax is used in the RTL/VCL code - can't check right now.

Hmm, my code got garbled somehow. Thanks for the correction.

You can use cast syntax - not sure how much that helps: const OTHER_FLOAT_CONSTANT Double0.005);

Only untyped constants are "real" constants. Typed constants are more like variables you can't change. That's just how Delphi works.

This would only apply if we're rearranging the used units inside a pas file. My question is about the project file, where you typically don't have much code.

Probably you both are right and I'm asking too much. FWIW: I don't want the units in the order they are first needed, just - as far as possible - dependent units after the units they use. If i find time I'll try to go with PAL's list and check if it makes a difference in compile time.

These are not mutually exclusive. E.g. PAL gives something like BusinessLogicA ThirdPartyA MyBaseStuffA BusinessLogicB ThirdPartyB MyBaseStuffB which satisfies the first bullet. I'd like to have ThirdPartyA ThirdPartyB MyBaseStuffA MyBaseStuffB BusinessLogicA BusinessLogicB which satifies both criteria. I guess this would be some kind of stable sorting based on the original uses order.

I'd like to sort the units used in our projects (*.dpr/*.dpk) by dependency. (I hope for faster compilations.) Are there tools to do that? PAL from Peganza outputs an "Optimal uses list" but that is rather "untidy" - e.g. third party units, my base units and the "business logic" all mixed together.

Seems like an array should be the way: type TMyFields = array[1..4] of TField; procedure TForm1.FormCreate(Sender: TObject); var LFields: TMyFields; i: Integer; begin for i := Low(TMyFields) to High(TMyFields) do LFields[i] := Query.FieldByName('FIELD' + IntToStr(i)); end;