Lars Fosdal

An IPv6 address is 128 bits. The answer is no. You'd need two UInt64s to hold that.

But isn't it still a value type? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types#how-to-identify-a-nullable-value-type

100% guesswork without any foundation, except name likeness, follows: There is a GetUnderlyingType property in System.RTTI type TRttiEnumerationType - but it is used absolutely nowhere in the RTL. Also, WinAPI.Ole2 contains a VariantChangeType, and WinAPI.ActiveX contains a VariantChangeTypeEx that may be relevant. System.VarUtils contain both. function TRttiEnumerationType.GetUnderlyingType: TRttiType; begin Result := Pool.TypeOrNil(TypeData^.BaseType); end; function TRttiPool.TypeOrNil(Value: PPTypeInfo): TRttiType; begin if Value = nil then Exit(nil); Result := GetType(Value^); end; function TRttiPool.GetType(ATypeInfo: Pointer): TRttiType; begin if ATypeInfo = nil then Exit(nil); Result := TRttiType(ReadObjectPointer(TRttiType, nil, ATypeInfo)); end;

I see. Personally, I rely on the MRU, Quick Access and Libraries functions that are built into the File Explorer. They are sufficient for me.

I am not sure if these are supported in Lazarus, but you could try an ActionMainMenuBar + ActionManager where you only use the top-level menu items. It would handle the hotkeys for you. ActionBarDemo.zip

@limelect What is the nature of the interaction between your app and the file explorer? Would it be better to launch your own explorer with CreateProcessEx? That way, your app would be the owner, and you would know when it closes, and if you need to launch another. In Windows 10, you can control if folder explorer windows should have separate processes by default or not. The default appears to be not, meaning each explorer opened (from f.x. using Win+E) actually is running in the same process. What is your setting? Does changing this setting affect your observable problem?

@Primož Gabrijelčič From the wishful thinking department: I'd love to see OTL evolve to support Linux/MacOS, iOS and Android. Hence, I'd love to see solutions that do NOT use Windows messaging - or at least hide it inside the notification implementation.

Is there a way to use it with "plugin" handlers instead on anonymous procedures? There are so many pitfalls with captures.

An alternative is to create completely independent classes, and use an interface to define the methods that you want to be general across the classes.

It requires some practice to wrap your head around encapsulation (pun intended) and thinking about how to make your code general or generic, if you like. A common base class mostly makes sense if you want to be able to ignore how it is used later, i.e. rely on polymorphism, and when you have a certain degree of reuse of code. Specific: Instance := TClassType.Create, then provide params -- Ideally, this would be the one place where you do something specific for the type when using it. General. Instance.LoadFiles; General: Instance.Compare; General: Output := Instance.CreateOutput; General: Render Output As you expand your hierarchy, you add properties and features only on the level where you need them. type TCompare = class procedure LoadFiles; virtual; procedure Compare; virtual; property File1: string; property File2: string; end; TCompare2Way = class(TCompare) procedure Compare; override; property Merge: Boolean; end; TCompare3Way = class(TCompare2Way) procedure LoadFiles; override; procedure CompareLeft; procedure CompareRight; procedure Compare; override; property File3: string; end;

Do you use MadExcept or Eurekalog or similar? There might be hints in the nature of the callstacks.

Just to rule out any db access issues - have you tried logging into the database with the same user credential and connection settings as your ODBC connection uses and running the query manually?

begin Memo1.Lines.LoadFromFile('Test.txt'); // loads the entire file as is into the memo It is a bit unclear what you want to do per line, and if it can be automated or not? Do you have a collection of files that you want to merge into the Memo ? var Filename: string; FileContent: TStringList; begin FileContent := TStringList.Create; try for FileName in ListOfFileNames do begin FileContent.LoadFromFile(FileName); // Process it in FileContent here Memo1.Lines.AddStrings(FileContent); end; finally FileContent.Free; end; end;

Users are a fickle bunch. Only devs are worse 😛

It would actually be nice to have something MDI like - but without the container. It would need multi-display support. The main window could be a narrow up top thing, or a sidebar thing.

Agree on the Joel thing - but the argument still stands with regards to MDI. Its demise has been plotted for at least two decades.

@Anders Melander: I may have been tooting the MS party line on MDI, without having read an actual deprecation statement, https://docs.microsoft.com/en-us/windows/win32/winmsg/multiple-document-interface "[Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, you should consider other models for your user interface. However, you can use MDI for applications which do not easily fit into an existing model.]" However, this thread by Joel Spolsky from 2002 (!) accentuates how long ago MS started pushing that party line... https://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixpost=2748 Basic functionality seems to be there, even with Per Monitor V2 - but I only gave it a cursory glance. I think I was on 1809 the last time I checked and at the time it was definitively borked. Currently on 1909.

The last time I checked, I got transparent client areas and border areas.

MDI has been deprecated for years and is severely broken under Windows 10. Seems that a lot of messages no longer are sent or passed down to children.

Does the DLL itself try to load a second DLL which cannot be found or is the wrong bit-ness?

Do you get error 193 in your 64-bit application? Is the DLL 64-bit?

Unless you need multi-pass processing, or you have logic for conditional processing further down.

I'd go for the C# approach instead of fiddling with an ancient Delphi.

Absolutely. The Law of Demeter is something I usually follow quite strictly. However, in the above example - Session.Progress.Truck.Required ( & alike), Session has already been validated and Progress is an object where all the fields are always populated. I actually did make this structure instead of having a buttload of local variables. I have to figure out if a value has been given, and if it is given, it is valid, and if not - if it is a required value, and so forth, and some login types may need only some of the parameters.

A "modern" way of handing conditions is to do early exit on condition fail. In the above case it is pointless, but for more complex sequences it can make sense. Here is an example from a piece of JsonRPC handling code I wrote. In this case I don't do exits - since there is stuff that happens after the validation. Imagine this code if I had used nested if/then... // Handle login progress errors if Result and Session.Progress.Device.Required then begin if Session.Progress.Device.FailAsError then Response.SetError(Session.Progress.Device); Response.SetHint(Session.Progress.Device.Message); Response.SelectNextStep(S01_Login); Result := False; end; if Result and Session.Progress.User.Required then begin if Session.Progress.User.FailAsError then Response.SetError(Session.Progress.User); Response.SetHint(Session.Progress.User.Message); Response.SelectNextStep(S02_SelectUser); Result := False; end; if Result and Session.Progress.Mission.Required then begin if Session.Progress.Mission.FailAsError then Response.SetError(Session.Progress.Mission); Response.SetHint(Session.Progress.Mission.Message); Response.SelectNextStep(S03_SelectMission); Result := False; end; if Result and Session.Progress.Truck.Required then begin if Session.Progress.Truck.FailAsError then Response.SetError(Session.Progress.Truck); Response.SetHint(Session.Progress.Truck.Message); Response.SelectNextStep(TPGStep.S04_SelectVehicle); Result := False; end; if Result and Session.Progress.Area.Required then begin if Session.Progress.Area.FailAsError then Response.SetError(Session.Progress.Area); Response.SetHint(Session.Progress.Area.Message); Response.SelectNextStep(TPGStep.S05_SelectArea); Result := False; end;