ddablib / verinfo Goto Github PK

Creation of required TCPInfoEx record could be rationalised.

There are numerous type names created as would be required if the the structure was a public API translation, but aren't used here.

Additionally, the ANSI and Unicode versions of TCPInfoEx are so similar that we can rely on compiler to compile correct version without explicit conditional compilation.

Here's what I suggest:

type
  TCPInfoEx = packed record
      // max length in bytes of a character in the code page
      MaxCharSize: UINT;
      // default character used to translate strings to the specific code page
      DefaultChar: array[0..MAX_DEFAULTCHAR-1] of Byte;
      // fixed-length array of lead byte ranges: all elements null if none
      LeadByte: array[0..MAX_LEADBYTES-1] of Byte;
      //  unicode default char used in translations from the specific code page
      UnicodeDefaultChar: WideChar;
      // code page value
      CodePage: UINT;
      // full localised name of the code page
      // - Char is automatically set to correct AnsiChar or WideChar by compiler
      // - depending on whether UNICODE is defined, so conditional 
      // - compilation isn't necessary
      CodePageName: array[0..MAX_PATH-1] of Char;
  end;

  PCPInfoEx = ^TCPInfoEx;  // *** only define this if strictly necessary 

Implicit casts to strings are defined, but explicit casts are not.

Continuing to support compilers prior to Delphi 2009 is problematic & I can't test them anything. In fact I can only test back to XE, so it may be worth dropping pre-XE support.

I've found the lack of a record constructor for TPJVersionNumber to be a problem.

Add one that takes four version numbers as parameters.

The component registration code really should be in separate design time unit.

Call this DelphiDabblet.Lib.VerInfoDsgn.pas

There's a public CompareVerNums function. An analogue for that as a class method of TPJVersionNumber would be useful from an encapsulation perspective.

Provide a class that is based on TObject rather than TComponent that provides much of the functionality of the present component.

I would drop the predefined string info properties in favour of string indexed array property and provide a const array that gives predefined string info names.

Current component could call into this class to do the real work.

Rename unit as DelphiDabbler.Lib.VerInfo.

.dcr file will need renaming similarly.

The will be a breaking change so needs introducing at the next major version release.

In

VerLanguageName is called like this:

if fHaveInfo and
  (VerLanguageName(GetLanguageCode, Buf, Pred(cBufSize)) > 0) then
  Result := Buf;

However the VerLanguageName docs say that if buffer size is too small, the language name is truncated. Also the number of characters written excludes the terminating null.

In practice the buffer used is probably large enough, but still the code is not best practice.

Maybe try something like example 2 from C++ (Cpp) VerLanguageName Examples - but note that the logic needs tweaking regarding buffer sizes.

delphidabbler/vilib#8 proposes pulling out the core functionality from vilib and releasing it as a separate library.

Should that code be merged into this library, or should a new one be created?

If the code is merged in here, how about placing the rwo different code bases in basic (for the current component) and advanced (for the vilib code)?

This will be an API breaking change so will need a major version bump. Given that, there's an opportunity to tidy up the API too.

Buffer size that is used to receive string file information is only 256 chars. This is too small for some of the string information in some of my programs.

WinHelp is way out of date & not supported at all on Windows 10 & 11.

Remove these files at the next major release.