Alexander Elagin

It compiles successfully if the error line is fixed like this: if (not a) or True then or this (I do not know the original intent of the statement): if not (a or True) then

I have used devices from Kvaser, IXXAT and some others. Kvaser has a superb support library (CANLib SDK) which includes Delphi interface module, their software model is very simple and elegant. IXXAT also used to have one, but I have not touched it since version 2.18 as the later versions of their VCI interface were incompatible with 2.x branch. Kvaser drivers implement virtual CAN channels which helps debugging when no real hardware is available.

There are two pairs of methods which differ only in register (getDocumentData / GetDocumentData and getDocumentStatus / GetDocumentStatus), that's why the imported module does not compile. Simply change these definitions like this, marking them as overloaded: function getDocumentStatus(const parameters: getDocumentStatus2): getDocumentStatusResponse2; stdcall; overload; and the unit will at least compile successfully. I have no idea if it will work as intended - hopefully yes because the parameters differ. As for the "cannot unwrap" note, this is pretty normal. This means that the importer could not extract individual parameters and imported them instead together as a class, this usually does not cause problems. Just take care with memory management.

Almost correct... you missed "T" character between the date and time parts: 2023-06-22 17:44:23.456 should be 2023-06-22T17:44:23.456 to represent a valid ISO 8601 date. (And probably a timezone but it is usually not required)

Because you have this declaration: ballpointer: PChar; PChar is an alias for PWideChar. WideChar is 2 bytes long. When pointer arithmetics is used, all operations take into account the real size of the data type the pointer points to. Thus, this statement: ballpointer := ballpointer+1; is in fact compiled and executed as ballpointer := ballpointer + 1*SizeOf(WideChar); and you have your pointer correctly pointing to the next WideChar in memory. This is really easy to check with a simplest program: program Project1; {$APPTYPE CONSOLE} uses SysUtils; var P: PChar; begin GetMem(P, 20); WriteLn(Format('P = %8x', [NativeUInt(P)])); P := P + 1; WriteLn(Format('P = %8x', [NativeUInt(P)])); ReadLn; end. You'll see that second value printed is greater than the first by 2 in any modern Delphi version. (Yes, I know there is a memory leak but this is just a demonstration).

Quoting the aforementioned RFC 2550:

There is a nice RFC 2550 dealing with dates up to year 10E30 and beyond (dated 1 April 1999 )

Just be sure that you never ever implement any business logic in visual form units (you know, those OnClick handlers...). Everything must be implemented in non-visual classes (including datamodules) not depending on any VCL units. Forms must be used only to call that functionality and display the results, if any. Thus you will finally get a nice set of units which can be further used anywhere, be it a UI-less server, console application, VCL or FMX.

Yes, surely. And it is possible to inherit an interfaced class not from TInterfacedObject, but from TSingletonImplementation which IS the base interfaced class without refcounting.

BTW, FreePascal has non-refcounted interfaces (CORBA/Java interfaces): https://www.freepascal.org/docs-html/prog/progsu37.html#x44-430001.2.37

There is a nice example in the InnoSetup documentation:

Finalization sections are executed in the reverse order to initialization, so the first unit to initialize will be the last one to finalize. From the documentation: The Finalization Section The finalization section is optional and can appear only in units that have an initialization section. The finalization section begins with the reserved word finalization and continues until the end of the unit. It contains statements that are executed when the main program terminates (unless the Halt procedure is used to terminate the program). Use the finalization section to free resources that are allocated in the initialization section. Finalization sections are executed in the opposite order from initialization sections. For example, if your application initializes units A, B, and C, in that order, it will finalize them in the order C, B, and A. Once a unit's initialization code starts to execute, the corresponding finalization section is guaranteed to execute when the application shuts down. The finalization section must therefore be able to handle incompletely initialized data, since, if a runtime error occurs, the initialization code might not execute completely.

A more or less easy solution would be to add the destructor call to the finalization section of Unit3: .... initialization tsTest := TStringList.Create; // or wherever it must be created finalization tsTest.Free end. And make sure that Unit3 is added to the project file before any form units: program Project1; uses VCL.Forms, Unit3 in 'Unit3.pas', Unit1 in 'Unit1.pas', {Form1} .... Not guaranteed but will probably work.

It just means that you have to write the missing constructor for the TTracksAddEditForm: constructor TTracksAddEditForm.Create(AOwner: TComponent; const AsMode: string; AiAlbum: integer; const AsTrack: string); begin inherited Create(AOwner); sMode := AsMode; iAlbum := AiAlbum; sTrack := AsTrack; end;

I was wrong ;-( There are in fact options to fold and unfold: Alt-Shift-1 to Alt-Shift-9 fold blocks of appropriate level, Alt-Shift-0 unfolds all.