Remy Lebeau

You did not setup your C++Builder code correctly to match the functionality of the Delphi code. Here is what your C++ code would need to look like instead to directly translate the Delphi code: //--------------------------------------------------------------------------- #ifndef examplecomponentcppH #define examplecomponentcppH //--------------------------------------------------------------------------- #include <System.Classes.hpp> #include <Vcl.Controls.hpp> #include <Winapi.Messages.hpp> class PACKAGE TExampleCpp : public TCustomControl { protected: MESSAGE void __fastcall WMMouseMove(TWMMouseMove& Message); public: __fastcall TExampleCpp(TComponent *Owner); __fastcall virtual ~TExampleCpp(); BEGIN_MESSAGE_MAP VCL_MESSAGE_HANDLER(WM_MOUSEMOVE, TWMMouseMove, WMMouseMove) END_MESSAGE_MAP(TCustomControl) }; #endif //--------------------------------------------------------------------------- #pragma hdrstop #include "examplecomponentcpp.h" //--------------------------------------------------------------------------- #pragma package(smart_init) __fastcall TExampleCpp::TExampleCpp(TComponent *Owner) : TCustomControl(Owner) { } __fastcall TExampleCpp::~TExampleCpp() { } void __fastcall TExampleCpp::WMMouseMove(TWMMouseMove& Message) { //... TCustomControl::Dispatch(&Message); } namespace Examplecomponentcpp { void __fastcall PACKAGE Register() { TMetaClass* classes[1] = {__classid(TExampleCpp)}; RegisterComponents("Samples", classes, 0); } } See Declaring a New Message-handling Method in Embarcadero's documentation. Note the inclusion of the MESSAGE_MAP, that is what actually hooks up the WM_MOUSEMOVE message to the WMMouseMove() method. As I mentioned earlier, an alternative would be to override the virtual TWinControl::WndProc() method instead of using a MESSAGE_MAP, eg: //--------------------------------------------------------------------------- #ifndef examplecomponentcppH #define examplecomponentcppH //--------------------------------------------------------------------------- #include <System.Classes.hpp> #include <Vcl.Controls.hpp> #include <Winapi.Messages.hpp> class PACKAGE TExampleCpp : public TCustomControl { protected: virtual void __fastcall WndProc(TMessage& Message); public: __fastcall TExampleCpp(TComponent *Owner); __fastcall virtual ~TExampleCpp(); }; #endif //--------------------------------------------------------------------------- #pragma hdrstop #include "examplecomponentcpp.h" //--------------------------------------------------------------------------- #pragma package(smart_init) __fastcall TExampleCpp::TExampleCpp(TComponent *Owner) : TCustomControl(Owner) { } __fastcall TExampleCpp::~TExampleCpp() { } void __fastcall TExampleCpp::WndProc(TMessage& Message) { if (Message.Msg == WM_MOUSEMOVE) { //... } TCustomControl::WndProc(Message); } namespace Examplecomponentcpp { void __fastcall PACKAGE Register() { TMetaClass* classes[1] = {__classid(TExampleCpp)}; RegisterComponents("Samples", classes, 0); } } But, that being said, in this particular situation you really should not be handling the WM_MOUSEMOVE message directly at all. Override the virtual TControl::MouseMove() method instead, eg: //--------------------------------------------------------------------------- #ifndef examplecomponentcppH #define examplecomponentcppH //--------------------------------------------------------------------------- #include <System.Classes.hpp> #include <Vcl.Controls.hpp> class PACKAGE TExampleCpp : public TCustomControl { protected: DYNAMIC void __fastcall MouseMove(TShiftState Shift, int X, int Y); public: __fastcall TExampleCpp(TComponent *Owner); __fastcall virtual ~TExampleCpp(); }; #endif //--------------------------------------------------------------------------- #pragma hdrstop #include "examplecomponentcpp.h" //--------------------------------------------------------------------------- #pragma package(smart_init) __fastcall TExampleCpp::TExampleCpp(TComponent *Owner) : TCustomControl(Owner) { } __fastcall TExampleCpp::~TExampleCpp() { } void __fastcall TExampleCpp::MouseMove(TShiftState Shift, int X, int Y) { //... TCustomControl::MouseMove(Shift, X, Y); } namespace Examplecomponentcpp { void __fastcall PACKAGE Register() { TMetaClass* classes[1] = {__classid(TExampleCpp)}; RegisterComponents("Samples", classes, 0); } } As I stated earlier, there is no equivalent to "inherited" in C++Builder. And there is no __super in C++Builder, either. Read that post again, it does not mention __super in relation to Borland/Embarcadero compilers at all, only in relation to Microsoft compilers. your only option in C++ is to specify the base class method directly. "inherited" in a Delphi message handler has no concept of public/private at all. Note that both the base class WMMouseMove() method in TControl and the derived class WMMouseMove() method in TExample are marked with the "message" directive (see Message Methods in Embarcadero's documentation). That means they are both stored in a message dispatch table that the compiler creates for every class that has "message" handlers. Calling "inherited" in a message handler will simply call the corresponding base class method in the dispatch table. It doesn't matter whether the methods are public or private. The table is just a bunch of method pointers. As it should be, because you are doing something COMPLETELY DIFFERENT than what the Delphi code is doing. There is no message dispatch table in C++. You are trying to directly call a base class method, and such a method call is subject to the standard public/private restrictions outlined in the C++ language. In the Delphi code, that is not the case. Because it can't be. C++ and Delphi are completely different languages, with their own set of rules and restrictions. Not everything translates across the language boundary, and "inherited" is one of them. There is nothing like "inherited" in C++. No, of course not. Plenty of components are written in C++Builder. I've written several myself. For the most part, it can. But certain methodologies may differ due to language differences. For instance, in this case the message dispatch happens to be different between Delphi and C++. Notice the MESSAGE_MAP in my example? That overrides the virtual TObject::Dispatch() method, and is why you have to call the base class Dispatch() method if you want to pass the message to a base class handler in C++. You are comparing apples and oranges here. You can't rationalize why one language doesn't behave the same as another language.

Your declaration of WTSQuerySessionInformation() is wrong. It should be like this instead: function WTSQuerySessionInformation( hServer: THandle; SessionId: DWORD; WTSInfoClass: WTS_INFO_CLASS; var ppBuffer: LPWSTR; var pBytesReturned: DWORD): BOOL; stdcall; external 'Wtsapi32.dll' name {$IFDEF UNICODE}'WTSQuerySessionInformationW'{$ELSE}'WTSQuerySessionInformationA'{$ENDIF}; And technically, both WTSEnumerateSessions() and WTSQuerySessionInformation() should be using 'out' parameters instead of 'var' parameters. But that is not important here. You are also leaking the memory that WTSQuerySessionInformation() returns. Try this instead: function GetSessionInfo(id: DWORD; var codeErr: Integer): TSessionInfo; var wpSessionInfo: PWTS_INFO; SessionInfo: LPWSTR; BytesReturned: DWORD; idErr: Integer; begin Result.ID := -1; try if WTSQuerySessionInformation ( WTS_CURRENT_SERVER_HANDLE, id, WTS_INFO_CLASS.WTSSessionInfo, SessionInfo, BytesReturned) then begin try Result.ID := id; wpSessionInfo := PWTS_INFO(SessionInfo); //user name Result.user := wpSessionInfo.UserName; //station name Result.StationName := wpSessionInfo.WinStationName; //domain name Result.domain := wpSessionInfo.Domain; //connection status Result.ConnectState := wpSessionInfo.State; finally WTSFreeMemory(SessionInfo); end; end else begin idErr := GetLastError; GV_TxtFileLog.Log('[GetSessionInfo] id ' + IntToStr(id) + ' ERR : ' + intToStr(idErr) + ' ' + SysErrorMessage(idErr), True); end; except on e: Exception do GV_TxtFileLog.Log('[GetSessionInfo] id ' + IntToStr(id) + ' EX : ' + e.Message, True); end; end; function SF_GetOpenedSessions(var codeErr: Integer): TSessionsInfo; var Sessions, Session: PWTS_SESSION_INFO; NumSessions, I: DWORD; SessionInfo: TSessionInfo; SessionCount: Integer; begin Result := nil; codeErr := 0; try if WTSEnumerateSessions(WTS_CURRENT_SERVER_HANDLE, 0, 1, Sessions, NumSessions) then begin try if NumSessions > 0 then begin SessionCount := 0; SetLength(Result, NumSessions); try Session := Sessions; for i := 0 to NumSessions-1 do begin if Session.SessionId <> 0 then begin GV_TxtFileLog.Log('[SF_GetOpenedSessions] GetSessionInfo '+ intToStr(Session.SessionId)); SessionInfo := GetSessionInfo(Session.SessionId); if SessionInfo.ID <> -1 then begin Result[SessionCount] := SessionInfo; Inc(SessionCount); end; end; Inc(Session); end; finally SetLength(Result, SessionCount); end; end; finally WTSFreeMemory(Sessions); end; end else begin codeErr := GetLastError; GV_TxtFileLog.Log('[SF_GetOpenedSessions] WTSEnumerateSessions err : ' + IntToStr(codeErr) + ' ' + SysErrorMessage(codeErr), True); end; except on e: Exception do GV_TxtFileLog.Log('[SF_GetOpenedSessions] EX : ' + e.Message, True); end; end;

There is no "inherited" in C++. You need to call the base class Dispatch() method. Or override the virtual WndProc() method instead of using a MESSAGE_MAP.

This is an English forum, please. I'm not familiar with the ScriptStringAnalyze API or how it works, so I can't help you further with this. I don't understand what you are trying to accomplish. Good luck with your journey.

There is a simpler way that doesn't involve keeping a second list. You can simply read in the INI values into a temporary unsorted TStringList first, and then you can loop through that list adding each entry to the live MRU normally, where the MRU insertion function looks for a duplicate in the live list and if found then removes it before then adding the new entry to the top of the list. I have updated my earlier example to demonstrate this.

It is commonly recommended that you should obtain a Network Named User license instead, so that you can then manage your own licensing locally without having to contact Embarcadero. You would just have to download and install the License Server onto a machine in your local network, and then you can issue/revoke your own licenses as needed.

You should not use TDirectory.GetCurrentDirectory() to get the EXE path, as the CWD is dynamic. It is subject to whatever path the launcher of the EXE wants to use, and it can also change value during the EXE's runtime. Instead, use TApplication.ExeName or ParamStr(0) to get the full path to the EXE file, and then strip off the filename with ExtractFilePath()/ExtractFileDir() or TPath.GetDirectoryName(). Though, you really should not be storing ANY mutable application data in the EXE's folder to begin with.

I suppose so. For example: procedure TMyForm.FormCreate(Sender: TObject); begin LoadMRUFromINI; end; procedure TMyForm.LoadMRUFromINI; var Ini: TIniFile; tempMRU: TStringList; I: Integer; begin Ini := TIniFile.Create('C:\path\settings.ini'); try tempMRU := TStringList.Create; try Ini.ReadSectionValues('mru' tempMRU); for I := 0 to tempMRU.Count-1 do begin AddPathToMRU(tempMRU[I], False); end; finally tempMRU.Free; end; finally Ini.Free; end; end; procedure TMyForm.SaveMRUToINI; var Ini: TIniFile; I: Integer; begin Ini := TIniFile.Create('C:\path\settings.ini'); try Ini.EraseSection('mru'); for I := 0 to PathsListBox.Items.Count-1 do begin Ini.WriteString('mru', 'path'+IntToStr(I+1), PathsListBox.Items[I]); end; Ini.UpdateFile; finally Ini.Free; end; end; procedure TMyForm.AddPathToMRU(const APath: string; AUpdateINI: Boolean = True); const MaxMRUItems = 5; var Idx: Integer; begin while PathsListBox.Items.Count >= MaxMRUItems do begin PathsListBox.Items.Delete(PathsListBox.Items.Count-1); end; Idx := PathsListBox.Items.IndexOf(APath); if Idx <> -1 then begin PathsListBox.Items.Delete(Idx); end; PathsListBox.Items.Insert(0, APath); if AUpdateINI then SaveMRUToINI; end; procedure TMyForm.DoSomething; var LPath: string; ... begin LPath := ...; ... AddPathToMRU(LPath); ... end;

I would do something like this: [mru] count=N path1=... path2=... ... pathN=... Keep adding new paths to the front of the list until the desired count is reached, then remove the oldest path from the end of the list each time a new path is added.

There is no such as a "TCP ping". Ping (ICMP) operates at a different protocol level than TCP. A ping can only tell you whether a machine/device is reachable on the LAN (assuming it even implements ICMP, and that ICMP is not being blocked by routers/firewalls, etc). But it cannot tell you whether there is an app actually listening on any TCP port on that machine/device. You would have to actually connect to a port to verify connectivity. That is what port scanners do.

Did you verify that DateTimeToStr() is actually producing a String that uses U+202F instead of U+0020? I can't imagine the RTL ever using U+202F on purpose, so it is likely coming from the OS configuration when the RTL reads in the OS's locale info. All the more reason NOT to rely on OS locales when saving your data. Use a more reliable format, like ISO-8601.

When I look at that .ini file, there is a Unicode character U+202F (Narrow No-Break Space) in between "11:15:12" and "AM". I think TryStrToDateTime() only supports the ASCII space character U+0020, so likely can't handle that other type of space character and so fails the parse.

The problem with that approach is that you may not get a decoding error, so you wouldn't really know which encoding "works" right away. You might just end up with garbage when reading data. And what do you consider to be "valid"? Because different formats can produce results without errors, but just won't be what you are expecting. Can you parse the string first to make an educated guess about its likely format before you then try to decode it as a TDateTime? Yes, and more than that, its the BOM for UTF-16LE specifically. So you can use TEncoding.Unicode when loading the file. Actually, internally TMemIniFile reads the file into a TStringList first before parsing it, and TStringList is smart enough to look for a BOM when no TEncoding is specified, so in theory TMemIniFile should be able to load your file in the correct encoding provided a BOM is always present and TMemIniFile.Encoding is nil. However... The file you have provided has a UTF-8 BOM, not a UTF-16 BOM. So your example code would need to use TEncoding.UTF8 instead of TEncoding.Unicode (or, don't specify the encoding at all and let TMemIniFile figure it out for you).

Ah! Stupid me, that joke went right over my head, I didn't even notice the 13 🤯

Where is System._CreateClass defined? I cannot find it in any RTL source file, and when I do a test creating a class instance from a metaclass, there is no such function call.

Even if you could get this to compile, you need to make the constructor virtual in order to call a derived constructor from a base metaclass type.

But you didn't explain earlier WHY you need to preserve the HDC, only that you want to use it across "two tasks", without any example or explanation of what those tasks actually are. And, as Delija already mentioned, you can simply Lock the TBitmap's Canvas to prevent the VCL from releasing the HDC automatically. Just make sure you Unlock it before you resize or free the TBitmap, and re-Lock it again after resizing. That makes no sense. If you are using the TBitmap's HDC for both functions, then there is no need to wait for a paint event to draw the string onto the TBitmap. Since you are not drawing the string onto a display HDC directly, there is no need to wait for a paint event. You can just draw onto the TBitmap whenever you want, since it is all just in-memory data. If you want to draw the TBitmap onto a display Canvas so the user can see the image, that certainly needs to be done in a paint event, but that does not mean you have to draw onto the TBitmap itself in the paint event. And in fact, you shouldn't do it that way. Prepare the TBitmap image ahead of time, and then just draw the TBitmap as-is whenever a paint event occurs, and then invalidate the display window whenever the TBitmap image changes so a new paint event can display the updated image. And this way, you don't even need the TBitmap's HDC to be persistent over time, you only need it when you are updating your image. For example: type TTextPanel = class(...) private procedure BmpChanged(Sender: TObject); procedure UpdateData; protected procedure Paint; override; procedure SetBounds(ALeft, ATop, AWidth, AHeight: Integer); override; public constructor Create(AOwner: TComponent); override; destructor Destroy; override; end; constructor TTextPanel.Create(AOwner: TComponent); begin inherited Create(AOwner); FBmp := TBitmap.Create; FBmp.OnChange := BmpChanged; end; destructor TTextPanel.Destroy; begin FBmp.Free; inherited Destroy; end; procedure TTextPanel.BmpChanged(Sender: TObject); begin Invalidate; end; procedure TTextPanel.Paint; begin inherited Paint; ... Canvas.Draw(0, 0, FBmp); ... end; procedure TTextPanel.SetBounds(ALeft, ATop, AWidth, AHeight: Integer); begin inherited SetBounds(ALeft, ATop, AWidth, AHeight); FBmp.SetSize(Width, Height); UpdateData; end; procedure TTextPanel.UpdateData; begin // update FBmp image as needed... end; I think you are making this task harder than it really needs to be. If you think I'm wrong, feel free to provide an example demonstrating exactly what you are trying to accomplish.

Then there is no point in calling getdbrecord() in the OnCreate event, since it will always fail to find a matching record. As it should be, since the user hasn't been allowed to type in a name yet! Then you need to perform a SELECT query without a WHERE clause. And then after you have called FDQuery1.Open(), you can call FQuery1.First() before reading the field values. type TfrmDino = class(TForm) ... private procedure displaydbrecord; public procedure get1stdbrecord; procedure searchdbrecord(const AName: string); end; procedure TfrmDino.FormCreate(Sender: TObject); begin WindowState := wsMaximized; get1stdbrecord; end; procedure TfrmDino.btnSearchClick(Sender: TObject); begin searchdbrecord(edtSearch.Text); end; procedure TfrmDino.displaydbrecord; var sName: String; img1: string; ... begin sName := FDQuery1.FieldByName('name').AsString; edtRecno.Text := FDQuery1.FieldByName('record').AsString; edtName.Text := sName; ... img1 := sName + '.jpg'; ... end; procedure TfrmDino.get1stdbrecord; begin FDQuery1.SQL.Text := 'SELECT record,name,meaning,pronounce,period,maingroup,size,lived,diet,factfile FROM dino'; FDQuery1.Open; FDQuery1.First; displaydbrecord; end; procedure TfrmDino.searchdbrecord(const AName: string); begin FDQuery1.SQL.Text := 'SELECT record,name,meaning,pronounce,period,maingroup,size,lived,diet,factfile FROM dino Where name = :PName'; FDQuery1.ParamByName('PName').AsString := AName; FDQuery1.Open; displaydbrecord; //edtSearch.Clear; end; Did you read the documentation yet? https://docwiki.embarcadero.com/RADStudio/en/Navigating_and_Manipulating_Records Even if you hook up the TDBNavigator to your DataSource, you don't have your UI hooked up to the Navigator, so of course nothing happens when you click the buttons. You would have to either use the TDBNavigator's events to re-query your records every time a button is clicked, or you should change your UI to use TDBEdit components and let them update themselfes automatically when the DataSource is navigated.

Why are you creating an HDC to begin with? TBitmap already has its own HDC that it manages for you. Just draw on your TBitmap whenever you need to. What are you trying to accomplish exactly by managing your own HDC manually? You don't need that 2nd step. You can't. Resizing a bitmap will destroy its old data. But TBitmap will handle copying the old data into the new memory for you. You would have had to do that yourself with a manual HDC, so better to just let TBitmap do it for you.

Simply set the TPageControl's ActivePage property back to Tab1, eg: procedure TfrmDino.getdbrecord; var ... begin ... PLTabSheet.ActivePage := TabSheet1; end;

OK, first problem... what do you see in the following snippet? (ignoring the unused img variables here) You are calling getdbrecord() in the Form's OnCreate event! What value does edtSearch hold when the Form is first created, BEFORE the user has a chance to type anything into it? Is it blank? Does it have a default value? We don't know, but I'm guessing it is not a valid record name. OK, next problem... see anything wrong with the following snippet? The sName variable is BLANK when you use its value to assign the img1 and img2 variables! Not that it really matters here, since you are not actually using those img variables for anything useful to begin with, but it is still something to be aware of so you don't make this same mistake again in the future. Lastly, just on a side note, in the following code snippet... You should be checking that TFDQuery.Open() actually found a matching record before you access the Field values. If TFDQuery.Open() does not find a match, the TFDQuery.Bof and TFDQuery.Eof properties will both be true, eg: ... FDQuery1.SQL.Text := '...'; ... FDQuery1.Open; if FDQuery1.Bof and FDQuery1.Eof then begin // no matching record found, do something... end else begin // place field data into tedit controls... end; Now, let's put all of that together... procedure TfrmDino.BitBtn1Click(Sender: TObject); begin Close; end; procedure TfrmDino.btnSearchClick(Sender: TObject); begin getdbrecord; end; procedure TfrmDino.FormCreate(Sender: TObject); begin WindowState := wsMaximized; //getdbrecord; end; procedure TfrmDino.getdbrecord; var sName: String; imgPath: String; img1: String; //img2: String; begin sName := edtSearch.Text; FDQuery1.SQL.Text := 'SELECT record,name,meaning,pronounce,period,maingroup,size,lived,diet,factfile FROM dino Where name = :PName'; FDQuery1.ParamByName('PName').AsString := sName; FDQuery1.Open; if FDQuery1.Bof and FDQuery1.Eof then begin ShowMessage('Name not found'); Exit; end; //place data into edtName edtRecno.Text := FDQuery1.FieldByName('record').AsString; edtName.Text := FDQuery1.FieldByName('name').AsString; edtMeaning.Text := FDQuery1.FieldByName('meaning').AsString; edtPronounciation.Text := FDQuery1.FieldByName('pronounce').AsString; edtPeriod.Text := FDQuery1.FieldByName('period').AsString; edtMainGroup.Text := FDQuery1.FieldByName('maingroup').AsString; edtSize.Text := FDQuery1.FieldByName('size').AsString; edtLived.Text := FDQuery1.FieldByName('lived').AsString; edtDiet.Text := FDQuery1.FieldByName('diet').AsString; memFactfile.Text := FDQuery1.FieldByName('factfile').AsString; //displayimages imgPath := 'D:\Delphi_11_Community\MyProjects\Dinobase\dino_images\'; img1 := sName + '.jpg'; //img2 := sName + '_size.jpg'; dinoImage.Picture.LoadFromFile(imgPath + img1); //edtSearch.Clear; end;

The only LoadFromFile() code you have shown us so far is in the form's OnCreate event before the SQL query is performed. Please show your updated code that calls it after the SQL query is performed. That is just a copy/paste of the example code I gave you originally. What does your REAL code look like? Did you put a breakpoint on imagePath, or show it in a ShowMessage(), or anything to verify it is holding the correct path before you then pass it to LoadFromFile()? No, it doesn't.

'group' is a reserved keyword in SQL. To use a reserved keyword in an object name, like a column field, you have to surround the name with square brackets, eg: FDQuery1.SQL.Text := 'SELECT record,name,meaning,pronounce,[group],period,size,lived,diet,factfile FROM dino Where name = :PName';

Please don't spread fake news. There is no such version. It is explicitly mentioned, in a roundabout way: Modeling is deprecated, and the current code formatter depends on it, so the formatter is also deprecated.

It is raw RGB, use whatever values you want for the R, G, B channels. The code you showed is not using a dark brown, it's more like a red-ish brown. RGB(80,47,15) is actually #502F0F in paint programs (not to be confused with the '#xxxx' character constant notation in Pascal!). It is not. Completely different RGBs. TColor(#575) is decimal 575 is hex $23F (use any calculator to verify that), and TColor($0000023F) is R=63($3F) G=2($02) B=0($00). RGB(80,47,15) would be TColor($0F2F50). If you want to set that in code, you can use the actual RGB() function: edtLived.Font.Color := TColor(RGB(80,47,15)); BTW, you may want to have a look at the TControl.ParentFont property. Instead of setting the Font.Color on every control individually, you can set it once on their parent instead, and then have the controls inherit it via ParentFont.