Uwe Raabe

Besides Interfaces there are also abstract classes to accomplish this. unit TestA; interface type TAbstractTestB = class public procedure Test; virtual; abstract; end; TTestA = class public M_TestB: TAbstractTestB; constructor Create; end; implementation uses TestB; constructor TTestA.Create; begin inherited Create; M_TestB := TTestB.Create; end. unit TestB; interface uses TestA; type TTestB = class (TAbstractTestB) M_TestA: TTestA; public procedure Test; override; end; implementation procedure TTestB.Test; begin end; end. Depending on where M_TestB is assigned, you assign either a TTestB instance or create one. You can even create that instance inside TTestA as you are allowed to use unit TestB in the implementation section of TestA as shown above. Nevertheless I suggest to remove these cyclic class dependencies altogether, but the way to do so depends heavily on your use case and the framework you are using.

There are several functions to simplify your task. You can use VarIsStr to check for string variants and VasIsOrdinal for the Integer case. Also there is VarToStr to convert a Variant to string. With this you can strip down your compare function to function CompareValues(const aValue1, aValue2: Variant): integer; overload; Begin Result := 0; // if ANY of the values is string, should compare as strings! if VarIsStr(aValue1) or VarIsStr(aValue2) then Result := CompareValues(VarToStr(aValue1), VarToStr(aValue2)) else if VarIsOrdinal(aValue1) and VarIsOrdinal(aValue2) then // Make sure that the following cast succeeds! Result := CompareValues(Integer(aValue1), Integer(aValue2)); End;

Seems you are mixing a boolean expression and a logical operator here ("=" is not a logical operator!). What do you expect from an expression like True and 8?

In general, no! Unless, in very specific scenarios, when the number you want to fill the array with consists of four similar bytes (like $04040404).

FillChar is a byte oriented method it will fill the underlying memory with the given number of bytes of the given value. Check Sizeof(a) and you will see that it is 24 and not 6. The UINT32 cast has no effect as FillChar will only use the lowest byte of that parameter.

It is indeed quite a while since I had to cope with BDE problems, so my suggestion might be pretty outdated now. Nevertheless you can give it a try as it is only a small change in the registry. What helped us in the past was disabling opportunistic locking at the server side (where the database files reside). For this you have to change the value of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\EnableOplocks from 1 to 0 (as 1 is the default value, it might even be absent). Note that you have to restart Windows to make this change effective. A drawback of this setting is a possible overall network performance drop for that server system.

I am not using SourceTree, so I cannot test. TortoiseHG has no problems cloning the repo.

Unfortunately, yes! Currently that is the only way to do that. I am aware that there is plenty of room for improvement in this plugin.

Unfortunately it is not easy to implement this. You will find the same problem with other IDE plugins trying to do the same. Unless someone finds a valid solution for this problem and is willing to share it I may need some time to invent something by myself.

Well, the OTA contains a few special interfaces regarding themes and the Unit Dependency Analyzer was the first form (or better frame in this case) making use of those. What I didn't know (because as usual those things are poorly documented - if at all) is that it seems to be forbidden to call ApplyTheme when IDE themes are disabled. Not that this could as well be caught inside ApplyTheme (just for safety - instead of crashing), so that not everybody has to add this additional check in their code.

To be honest, I usually test only against an IDE with all options at default. It is near to impossible to test for all combinations. It was my hope that such things are discovered during the beta phase.

What about F11?

@ULIK Oops! Please give version 14.0.4 a try.

Official version 14.0.3 with support for Delphi 10.3 is now available. There have been only some small bugfixes since the beta version (f.i. beta still used the v13 registry key).

Are you looking for Kiosk mode? Configure kiosks and digital signs on Windows desktop editions

A plain <Enter> should do as well.

Noted!

He was probably mislead by my code example, which actually was a console application.

As long as the form is derived from TDockForm there is no way to make it not dockable (after all that is the main purpose of a TDockForm descendant). On the other hand you are not forced to dock it in the first place. The desktop functionality isn't affected from the docking state. To store the last position of the floating window in the desktop it is sufficient to make it visible once any time before saving. It is not necessary to dock the form for that.

Seems you are looking for TTimeSpan: program Project458; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.TimeSpan; var span: TTimeSpan; begin span := TTimeSpan.Subtract(EncodeDate(2018,1,2)+EncodeTime(16,35,0,0), EncodeDate(2018,1,1)+EncodeTime(15,30,0,0)); Writeln(Format('%d Day(s) %d Hour(s) %d Minute(s)', [span.Days, span.Hours, span.Minutes])); Readln; end.

program Project458; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.TimeSpan; var span: TTimeSpan; begin span := TTimeSpan.Subtract(EncodeDate(2018,1,2)+EncodeTime(16,35,0,0), EncodeDate(2018,1,1)+EncodeTime(15,30,0,0)); Writeln(Format('%d Day(s) %d Hour(s) %d Minute(s)', [span.Days, span.Hours, span.Minutes])); Readln; end.

Are you aware that the Source Indexer window is part of the desktop and thus stored with it? You can move it wherever you want or dock it to a suitable place, save the desktop and it is restored whenever the desktop is loaded again. The position is also stored in the desktop when the Source Indexer is not visible anymore while saving. I know this is not the same as storing the last position, but unfortunately both storage mechanisms don't play together nicely. The other suggestions are in the issue tracker now.

Well, I assumed that changing the filename is done via Save As, which already takes care of that. The same is true for renaming a unit from inside Project Manager.

Yes, that is all you need to do: Change the filename.

There is a beta for Rio as announced in this thread: https://en.delphipraxis.net/topic/287-mmx-for-delphi-103-rio/ Although there are still some minor glitches (e.g. using the v13 registry key than the v14 one), it seems to work quite reliable. When I find some time during the next days I will provide an official release. BTW, the Use Unit dialog of MMX allows to add predefined modules, which are just groups of unit names. Click the small wizard symbol to the right from the edit field. This is quite helpful when you have to add several units that somehow belong together and are often needed in full.