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.

3 hours ago, Anders Melander said:

Okay, so I would recommend that you simply start with the RTL TThread. Mainly because it appears that you have no prior threading experience (or you probably wouldn't have asked in the first place) and it would be best to learn the basics before trying something more advanced. Threading might seem easy but it's actually really difficult if you don't know and understand the many things that can go wrong.

 

I would also avoid the various 3rd party threading libraries, even though I'm sure they can do some nice things, so you don't introduce external dependencies and get locked in to their way of doing things. Once you know a bit more you can make an educated decision about which way to go.

 

The PPL was introduced in XE7 but I think it took a while for it to become reliable(ish). I stayed clear of all the versions between XE2 and Delphi 10 so I don't have first-hand experience with those versions. These days I seldom use TThread directly. Most of my thread tasks are short lived so they benefit from the TTask thread pool (and TTask is just so much nicer to use).

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.

56 minutes ago, Anders Melander said:

 

OP is on Delphi 2007...

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?

14 hours ago, David Heffernan said:

Does it even compile, and if so what does it mean? 

My fragment wouldn't have compiled. And as stated I'm not sure if it helps with this:

On 9/27/2024 at 6:16 AM, Tommi Prami said:

Make sure, some constant is always Double, not extended, in 32bit and also in 64bit...

That might depend on the scenario. IIRC this syntax is used in the RTL/VCL code - can't check right now.

17 hours ago, Remy Lebeau said:

const
  OTHER_FLOAT_CONSTANT = Double(0.005);

 

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

3 hours ago, Tommi Prami said:

If type could be defined for const could make some code cleaner. Make sure, some constant is always Double, not extended, in 32bit and also in 64bit...

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.

34 minutes ago, Vandrovnik said:

The new unit order can have unintended side effects - if two unites define procedures with the same names and their order is swapped, the code will use a different procedure than before (such as System.Math and Neslib.FastMath do).

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.

40 minutes ago, Anders Melander said:

• Sorted by dependency
• Sorted by "some other criteria"

Pick one

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;

16 hours ago, Patrick PREMARTIN said:

It's not new : destroy of the main form and finalization bloc in units is not executed on Mac since years.

 

On Mac, for the main form use the onClose event instead of onDestroy.

Is this the cross-platform development I keep reading about? 😎

Turkish has two kinds of I - one with dot and one without. Their case-handling is special. See Dotless I - Wikipedia.

For me editting $DEFINEs and $IFDEFs sometimes breaks syntax highlighting - everything after the directive is colored like a preprocessor directive. (But I'm still on XE6)

If you don't want to change the order of parameters you can use two overloaded  functions like this:

interface

function GetWeekDates(const GivenDate: TDateTime; const SOWDay: string; out startDate, endDate: TDateTime): Boolean; overload;
function GetWeekDates(const GivenDate: TDateTime; out startDate, endDate: TDateTime): Boolean; overload;

implementation

function GetWeekDates(const GivenDate: TDateTime; const SOWDay: string; out startDate, endDate: TDateTime): Boolean;
begin
  //...
end;

function GetWeekDates(const GivenDate: TDateTime; out startDate, endDate: TDateTime): Boolean;
begin
  Result := GetWeekDates(GivenDate, 'SU', startDate, endDate);
end;

Alternatively, drop the overload and use different names like GetWeekDates and GetWeekDatesEx.

I see - thanks for the info, Uwe. And for all the useful tools. 🙂  

In our app we have some DXF related units whose names start with "Dx" or "DX". We also use DevEx and they have lower case "dx". So I'd like to have dx* case-sensitively grouped as third-party but left D* alone.

Is there an option to make UsesCleaner do that?

28 minutes ago, Uwe Raabe said:

Unfortunately that is by design as comments in uses clauses are considered not clean.

 

Background: It is pretty hard to connect the comment to one of the used units - there is too much convention involved with this. Also, line end comments don't play well with grouping and line wrapping.

 

There are non plans to change this any time soon.

Thanks for the info, Uwe - I already suspected this. Fortunately, it's not a big problem. 

Hi all,

I recently started using UsesCleaner and mostly love it. One mildly annoying aspect is that it removes comments after units in the uses clause. I often have clauses like

uses
  Unit1, // PALOFF - to suppress false positives from Pascal Analyzer 
  Unit2, // used because of some obscure reason
  Unit3; // TODO remove when ...

and have to reinstate all the comments after using UsesCleaner. Is there a way to make UsesCleaner leave the comments in place?

Next nitpick: If the Instant Grep window is focussed, pressing Shift-Alt-S brings up the Grep submenu. If I dismiss it (by clicking somewhere else) the expected Grep dialog shows.

MInor issue: Clicking the "Case sensitive" checkbox doesn't update the search.