Remy Lebeau

v13 has not been released yet, and no information about its pricing is available at this time.

In a word, no. Certainly not directly, anyway. Basically. Load the DLL into a 64bit process, and then use some kind of IPC with the 32bit process. The article is using C#, but the technique is not limited to C#. A COM out-of-proc server is aits own EXE process, and can be instantiated by 32bit and 64bit clients. So, you can write a 64bit server that wraps the 64bit DLL (or use COM's own DllSurrogate if the DLL is itself a COM object) , and then a 32bit client can use the server's COM object. I'm not familiar with that. It looks interesting but I wouldn't trust it in production code.

The Result variable (enabled by default via the {$EXTENDEDSYNTAX ON} / {$X+} directive) has been available for a very very long time, much earlier than 2000. But even so, assigning values to the function's name is still an allowed option, too.

Your descriptions are a bit confusing. Can you show the updated code that is not working the way you want?

Obviously, I'm aware of the existence of class procedures/functions, but I've never seen a "procedure of class" declaration before. I didn't know that was a possibility. In any case, a "class" procedure/function still has a hidden Self parameter, it simply points at the class type instead of an object instance. Your code is not taking that parameter into account. You have to declare a "class" procedure/function as "static" in order to remove its Self parameter.

There's no such thing as an "active" class method. Non-static, dynamic, virtual methods - these all have a hidden implicit Self pointer to the object instance they are called on. Yes, because they will all be using the Self pointer. For example procedure TForm5.FormClick(Sender: TObject); begin ABCycle.Visible := True; end; Is really this: procedure TForm5.FormClick(Sender: TObject); begin Self.ABCycle.Visible := True; end; If such a procedure is trying to access members of the Form of object, then yes. I suggest you brush up on your fundamentals. For instance: https://docwiki.embarcadero.com/RADStudio/en/Procedures_and_Functions_Index https://docwiki.embarcadero.com/RADStudio/en/Classes_and_Objects_Index https://docwiki.embarcadero.com/RADStudio/en/Methods_(Delphi)

Since we can't see the rest of your code, we can't help you with these errors. The sole function you have shown only had one mistake in it. So clearly these other errors are caused by other problems (likely other syntax mistakes) higher up in your code that we can't see. Because clearly THIS unit has other mistakes in it that are breaking its compilation. Obviously yes, but what that flaw could be specifically is anybody guess without seeing the rest of the code in question. That behavior happens when the failing code is NOT inside a non-static method of the TForm5 class, thus requires an explicit object reference to reach the ABCycle member. It doesn't matter if you have 1 Form or 100. You need a valid TForm5 object reference in order to access its ABCycle member. Inside of a method of the TForm5 class, that reference can be the implicit 'Self' pointer. But code outside of TForm5's methods will need an explicit pointer to the Form5 object. That behavior would happen if DaysInMonth() is a non-static method of the TForm5 class, and thus must be called on a valid Form5 object reference, but the calling code does not have such a reference without qualifying it.

FYI, the SysUtils unit has an IsLeapYear() function, and a MonthDays[] array, eg: uses ..., SysUtils; function DaysInMonth(Mo, Yr : Word): Word; begin Result := MonthDays[IsLeapYear(Yr), Mo]; end; Alternatively, the DateUtils unit has its own DaysInAMonth() function, eg: uses ..., DateUtils; function DaysInMonth(Mo, Yr : Word): Word; begin Result := DateUtils.DaysInAMonth(Yr, Mo); end; No need to reinvent the wheel here...

I would choose the latter. No need to allocate memory dynamically unless the record instance needs to live after TObj.run3() exits. But, if you have a lot of methods of TObj that are acting on the record then they should instead be methods of TRecord itself. Consider refactoring your code to make it cleaner.

The Width/Height properties of the global Screen object return the size of the primary monitor only. If you want the size of the monitor that your program is displayed on, use the Width/Height or DisplayRect properties of the TForm.Monitor property. That code assumes all monitors are positioned only side-by-side horizontally, it does not account for monitors being stacked vertically. To get the total Width/Height of the virtual screen, use the global Screen object's DesktopWidth/DesktopHeight or DesktopRect properties.

Why use TWICImage and not TPNGImage?

As it should. That is one of the pre-defined places where the DLL loader looks for dependant DLLs. That means the DLL could not be loaded. Either you used the wrong path, or a dependency could not be found, etc. Did you try using a Delay Load failure hook to find out exactly what is failing? See the example in Delphi's documentation

No, it will not work. Although it will load the DLLs at process startup, you have no control over the order in which static-linked DLLs are loaded. More importantly, you CANNOT specify the paths where to search for static-linked DLLs, The resulting IMPORTS table simply does not contain paths, only filenames. Statically-linked DLLs are always searched for in system-defined paths only, see: Dynamic-link library search order. So, if your app needs to control the paths where DLLs are loaded from, then you MUST use dynamic/delayed loading.

Why are your DELETING lines you are trying to WRITE to? Also, you are not taking into account that the line indexes will CHANGE when you delete lines, so you are actually deleting the 1st 3rd 5th lines, not the 1st 2nd 3rd lines. Simply don't do this. You don't need the Delete() calls. procedure TForm1.Button1Click(Sender: TObject); begin Memo1.Lines [0] := Label1.Caption; Memo1.Lines [1] := Label2.Caption; Memo1.Lines [2] := Label3.Caption; end; procedure TForm1.Button2Click(Sender: TObject); begin Label1.Caption := Memo1.Lines [0]; Label2.Caption := Memo1.Lines [1]; Label3.Caption := Memo1.Lines [2]; end; But, if you must delete lines, then you can simply Insert() them back in, eg: procedure TForm1.Button1Click(Sender: TObject); begin Memo1.Lines.Delete (0); Memo1.Lines.Delete (0); Memo1.Lines.Delete (0); Memo1.Lines.Insert(0, Label1.Caption); Memo1.Lines.Insert(1, Label2.Caption); Memo1.Lines.Insert(2, Label3.Caption); end; But, I still stand by my earlier comment that this is really the wrong UI choice to use in the first place.

What you are asking for can't be done if you use static linking. You would have to modify the system PATH in order to find the secondary DLLs that libheif.dll uses. You need to load libheif.dll dynamically at runtime instead. You can either rewrite your code to load libheif's function(s) explicitly via manual calls to LoadLibrary()+GetProcAddress(), or you can simply mark the functions as delayed to let the RTL handle the loading for you. But either way, this will allow you to call SetDllDirectory() or AddDllDirectory() at runtime before you call any of libheif's functions for the first time.

In a VCL TMemo, if you try to read from a line index that doesn't exist then the output string will be blank, and if you try to write to a line index that doesn't exist then the input string will be ignored. No errors are raised. So, in your case, for example, if you try to write to Memo1.Lines[2] when Memo1 does not have at least 3 lines, then your LblLastName.Caption string will be ignored. So, like Brian said, you have to make sure a given line actually exists before you can read/write it. That being said, using a TMemo probably isn't the best choice for this task to begin with. Why not use 3 TEdit's instead? Or maybe a TStringGrid, or a TValueListEditor, or an editable TListView instead? There are many choices, depending on your UI needs.

They are the same product. The original author passed away. Embarcadero had to renegotiate a new deal with his estate in order to continue providing the product. So any emails should be directed to Embarcadero. Embarcadero will continue developing and providing FMXLinux as an option, but only for Enterprise and Architect with Active subscription, AFAIK.

That's a little overkill just for loading an ini file. And you'd still need startup code to start the thread.

If you need to run code that is related to your UI, you can use your MainForm's OnCreate event. If you need to run code sooner than that, then you can add code in your project's .dpr file before Application.Run() is called. Or, you can put code in the initialization section of any .pas file in your project.

Why are you reading the mDate field as a String and not as a TDateTime to begin with? And are you populating your UI controls manually instead of using data-aware controls? If using a data-aware UI, you can configure a data field to *display* in a particular format, without having to actually pull the data and format it yourself. You say you have a date/time field, but then you talk about a Memo field. Which one are you actually parsing? I'm still not clear where your error is. Your screenshots don't match the code snippet you provided.

? There is no mdata in the code you provided. Do you mean dbdate? The code I presented is just a simplification of the code you provided, so it should compile. StrToDate() returns a TDateTime, and TryStrToDate() outputs a TDateTime. TDate is just an alias for TDateTime.

If you use TryStrToDate() instead then you can avoid the try..except, eg: if TryStrToDate(qry.FieldByName('mDate' ).AsString, dbDate) then dateS := FormatDateTime('yyyy-mm-dd ddd', dbDate) else sb1.Panels[0].Text := 'Error: invalid date!';

I didn't say it was *submitted* for merge into FPC. I said it was *created*. There is a patch file attached to the forum post that I linked to: "It's roughly 30 lines of code and took 15 minutes to create the attached patch for fpc main"

Actually, a patch was already created for FreePascal to add this very same conditional operator (FPC already had an IfThen() intrinsic); https://forum.lazarus.freepascal.org/index.php/topic,71398.msg556926.html#msg556926

Not really, not without knowing what code actually crashed, and what it was actually trying to do at the time of the crash. Debugging via forum isn't a good way to handle this. You need to actually debug the program directly and try to reproduce the issue. You say you have 2 threads trying to talk to the same device, presumably over a single connection. Best to give each thread its own connection if possible. Otherwise, I would suggest delegating all I/O on that connection to a single thread and let it accept queries from, and return responses to, other threads as needed.