Leaderboard

I just released my NCG library as open source on GitHub. The full library description and documentation here. Discussions: I think it might be the only NGS Pascal library out there... The program works quite fine but it speed is not impressive... on the other hand is does not have any optimization and it is single threaded. If you have multiple patterns to look into the "big" image, each one could go into a thread. On a CPU with 12 cores, like mine, this code could easily behave as and OCR 🙂 Pre-compiled demo program also available. Enjoy. ____ Related to image processing: You will find also some basic image processing code in my LightSaber lib. There is another library that I will make it also open source that adds metadata to an image, so you can autorotate it based on exif, add "stars" to it (how much you like, it), pregenerated thumbnail (to save some time CPU next time you show it), etc. So, stay tuned... 🙂 ____ PS: On Git hub, vote only the libraries you like 🙂 🙂 🙂 I invest time in those that get votes 🙂

Hey Y'All, With a possible code challenge in mind, I've created a framework to aid programmers with creating card games. You can find it here: objpas-card-framework Opinions, advice and PRs are very welcomed!! Especially because I'm aiming at getting a set of Delphi packages, and I need someone to create them. Cheers, Gus

MechaHitler surely

No, you should use separate units for each form and keep the {$R *.dfm} directive in each. The * makes it match with the unit name and the IDE will keep unit and form file names in synch. Please refrain from packing multiple forms into one unit. Otherwise you will most likely flood this forum with questions about the problems you get, while the correct answer will always be: Don't do that!

I don't have installed Lazarus on my VM but I didn't see where you store the cards images in your source files. If you need some I've just created this repository from David Bellot SVG Cards with individual SVG images, PNG images and Delphi samples of use : https://github.com/DeveloppeurPascal/SVG-cards

If the NTA offers advantages to your plugin you can always add that later. Whether that's the case depends on what your plugin does.

Thanks to the help of @Keesver and @pmcgee I now have quickjs-ng building with MINGW in WSL for Win32 and Win64. It would have been nice to get them building with native windows tooling but alas that's just too hard due to how the project is setup (ifdef hell). My next challenge will be to get his automated on our CI servers (server 2019) which currently do not have wsl installed. I added a windows resource file (winver.rc) so I can set the version number. #include <windows.h> 1 VERSIONINFO FILEVERSION 1,0,0,0 PRODUCTVERSION 1,0,0,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x2L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "FileDescription", "QuickJS NG" VALUE "FileVersion", "1.0.0.0" VALUE "ProductName", "QuickJS NG" VALUE "Comment", "Compiled by VSoft Technologies Pty Ltd" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END FWIW - this is the makefile I ended up with - just provide the ARCH on the command line, e.g make -f Makefile_win ARCH=64 Makefile_win ARCH ?= 32 ifeq ($(ARCH),32) CC = i686-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = i686-w64-mingw32-windres --preprocessor=i686-w64-mingw32-gcc --preprocessor-arg=-E --preprocessor-arg=-xc-header --preprocessor-arg=-DRC_INVOKED RC_FLAGS = --target=pe-i386 else CC = x86_64-w64-mingw32-gcc CFLAGS = -O2 -fPIC -Wall -D_GNU_SOURCE -DCONFIG_VERSION=\"V16\" LDFLAGS = -static -shared RC_COMPILER = x86_64-w64-mingw32-windres RC_FLAGS = endif OUT_DIR = Win$(ARCH) RC_FILE = winver.rc RES_FILE = $(OUT_DIR)/winver.o SRC = quickjs.c libunicode.c libregexp.c cutils.c libbf.c quickjs-libc.c OBJS = $(patsubst %.c,$(OUT_DIR)/%.o,$(SRC)) TARGET = $(OUT_DIR)/quickjs-ng$(ARCH).dll all: $(OUT_DIR) $(TARGET) $(OUT_DIR): mkdir -p $(OUT_DIR) $(OUT_DIR)/%.o: %.c | $(OUT_DIR) $(CC) $(CFLAGS) -c $< -o $@ $(RES_FILE): $(RC_FILE) | $(OUT_DIR) $(RC_COMPILER)$(RC_FLAGS) -i $(RC_FILE) -o $(RES_FILE) $(TARGET): $(OBJS) $(RES_FILE) $(CC) $(LDFLAGS) -o $@ $^ clean: rm -rf win$(ARCH) Thanks again for all the help.

Hi All I'm looking at getting QuickJS working in Delphi. Sadly my C skills are not at the level needed to get anything to build in CBuilder or Visual Studio these days - it's not the same language I used 30+ years ago. There are a bunch of forks of this project, and I am pretty sure I have tried them all but have yet to get a completely successful build - probably because I don't know what I am doing. Ideally I'd like to be able to generate Win32/Win64 object files that I can link into delphi, or if that isn't feasible then a dll that I can load. Prefer C++ Builder but failing that Visual Studo 2022 is also an option. The C code apears to be written for GCC and supports Win32 via MINGW. I am willing to sponsor someone to work on this if needed. DM me if interested. Timeframe is asap!

Multi-phase extension module initialization has been implemented. See Multi-phase module initialization implemented · pyscripter/python4delphi · Discussion #505 for details. What this means is that you can now create python extension modules with P4D that can be used with sub-interpreters including those created with the new concurrent.interpreters module of python 3.14.

I know... I know... (On the other hand I sold all my Tesla stocks).

Yes, ActiveScripting has been abandoned by Microsoft - which would be fine if they just made sure it continued to work for a while, but they recently completely broke it - https://www.finalbuilder.com/resources/blogs/finalbuilder-and-automise-on-windows-11-24h2 We have a ton of existing javascript, as do our customers (each action has events customers can write scripts on), so it's not simply a a case of swapping out scripting languages. I did look at p4d a while ago but ran into issues - I don't remember the specifics (something around threading - finalbuilder is multi threaded). It's on my todo list to look at again when time permits. We currently have iron python support, but have been telling customers not to use it for some time due to memory issues. Swapping that out for for P4D might sound like a no brainer but Iron Python allows people to use .net framework classes. What ever happens, we're going to have some unhappy customers. Tech debt sucks!

I'm looking to replace MS ActiveScripting in FinalBuilder.

Hi everyone, I wanted to share the main updates in version 1.1.0 of DelphiGenAI (OpenAI wrapper for Delphi) here—mainly to offer what I can to the community, and maybe get some feedback if anyone feels like weighing in on my approach. Main Updates Compatibility with the Latest OpenAI Features (including Remote MCP & Code interpreter) Ready-to-Use Templates Two archives (TestGenAI_VCL.zip and TestGenAI_FMX.zip) let you copy and paste any snippet from the documentation and test it out, with no complicated setup. Variety of Code Snippets For each feature: synchronous, asynchronous (event/callback), and asynchronous with async/await. The idea is to allow everyone to compare the approaches and pick the one that fits them best. Documentation That’s Directly Usable All markdown examples can be tested as-is within the supplied templates. A Gradual Learning Path The aim: make it easier to learn about AI in Delphi, whatever your starting level, and to keep things as accessible as possible. About This Approach I’m not an experienced “Delphi old-timer” and I don’t know the community very well yet; that’s why I chose to offer several approaches (synchronous, asynchronous, and async/await) for each example. But maybe that’s not really necessary—maybe some would prefer strictly asynchronous, or even just synchronous? I’d be interested in your thoughts or experiences on this (no pressure—just curious, and trying to do what's most helpful). Also Tried on Other Wrappers I’ve used the same principle in a Delphi wrapper for Deepseek. Depending on the feedback I get here, I’ll decide whether to take this approach with a few other wrappers I’ve put up on Github. Thanks in advance for reading, and best wishes to all.

By the way, TThread.Yield is the cross-platform way to call SwitchToThread.

I think all is linked to the time of SO post, 15 years ago. Talking about CPU here is about CORE, when there are multiple CPU other things come in play and the sleep is the last of the issues. Take care now ( @Kas Ob. told this) that the real life is different: no one use affinity with one thread (yes, I do it but for really unique needs), the threads work are balanced by ITD (Intel Thread Director) that acts between OS and hardware, and also Windows may have changed some logics. If you look at your thread (not the one in the example that's "blocked" by Affinity), you'll see that it's "moved" by core during its lifetime. That is, a thread doesn't necessarily always run in the same core. So, if Microsoft were to say that SwitchToThread works in a certain way with modern hardware... well, I wouldn't be so sure, or rather, not in the context we're imagining, given that the load distribution is dynamic.

How upgrading from Delphi 7 to Delphi 12 eliminated 15 monthly support tickets and unlocked Linux deployment In May 2024, we were contacted by a European leader in natural gas measurement systems. Their software was partly built in Delphi 7 and partly in C#. It had become difficult to maintain. The company wanted to migrate to Delphi 12, modernize the UI, and enable Linux deployment, without breaking existing functionality. Our team faced and handled the following challenges: The project relied on Delphi 7. That version lacked full Unicode support. The framework used ANSI strings by default, and this created critical limitations for modern global applications. The legacy app only ran on 32-bit Windows, using outdated Win32 APIs and hardcoded paths (C:\Data\). This prevented deployment on Linux cloud servers (AWS/Ubuntu). The app was built on obsolete BDE components and unsupported libraries. Here's what we did: ✅ Migrated from Delphi 7 to Delphi 12 ✅ Replaced BDE and Indy 9 with FireDAC and Indy 10 ✅ Refactored code for cross-platform compatibility ✅ Delivered a modernized UI with preserved workflow familiarity We achieved: - 15 support tickets per month were reduced to zero - Windows-only application is now cross-platform - Overall, the application is more prepared for future challenges A few months later, the client returned for an estimate to migrate other Delphi projects to a web-based platform. If you want to see the full story, with the challenges and solutions broken down, follow the link https://www.softacom.com/cases/modernizing-industrial-software-with-delphi-12/

Firewall was off on the Mac already. Closed down and restarted and messed around with some settings and it all started working. Just another Delphi refreshing issue from the looks of things.

Pascal code is compiled top-down in a single pass. DEFINE, IFDEF, etc are compiler directives that are evaluated only at compile-time. The resulting code is fixed, it cannot be changed at runtime. If you try to IFDEF something before it has been DEFINE'd, the result will be False. Hence the name IF-DEFined. In any case, DEFINE/IFDEF is not the correct solution for your problem anyway. You are making a decision based on data known only at runtime, so you need to add an extra parameter to your function that is called at runtime (you need to add a Sender parameter, too), eg: function doTheReport(Sender: TObject; Bo: Boolean); begin if Bo then Result := DoCharges(true, -1, False, False, False, lg('CLOSE CHARGES'), '1', dm2.SysDate.FieldByName('date').AsDateTime) else Result := DoCharges(Sender=nil, -1, False, False, False, lg(TDsFancyButton(Sender).Caption), '', 0, dm2.SysDate.FieldByName('date').AsDateTime); end; function selectReport(Sender: TObject); begin doTheReport(Sender, Sender = good1); end; Alternatively: function doTheReport(Sender: TObject); begin if Sender = good1 then Result := DoCharges(true, -1, False, False, False, lg('CLOSE CHARGES'), '1', dm2.SysDate.FieldByName('date').AsDateTime) else Result := DoCharges(Sender=nil, -1, False, False, False, lg(TDsFancyButton(Sender).Caption), '', 0, dm2.SysDate.FieldByName('date').AsDateTime); end; function selectReport(Sender: TObject); begin doTheReport(Sender); end;

Not that it solves your RestDebugger but, but there is also a nice tool Bruno, which might help to dig deeper. https://www.usebruno.com/

@weirdo12 I had today the same Clang problem, thanks for your post.

If a "host" application is designed to use form classes implemented in dynamically loaded packages the host app has ( should have) no idea how the form classes are named. To make this into a truely modular and extensible application you need a design like the one used by the RAD Studio IDE. The app only knows where it has to look for extension modules to load (a folder or a registry or other configuration store listing the module file names). The modules register the form classes when loaded into a factory class or list implemented in a statically bound package used by host and all form modules. The host app can then enumerate the available forms using this factory to offer the selection to the user, check if such a form has already been created by searching through the Screen.Forms collection by class name, and, if not found, create an instance using a local variable that cannot be accessed from other parts of the app. If a form reference is needed elsewhere it has to be retrieved from Screen.Forms or another list, e.g. (for MDI child forms) the MDI frame form's MDIChildren collection. Doing it this way decouples the modules and even makes it possible to add modules without having to rebuild the host app. If one of the dynamically loaded forms uses a data module it should override the constructor and check for the presence of the DM before calling the inherited constructor and create an instance of the DM if necessary. I have a strict policy of immideately deleting the IDE-created global variables for forms and DMs if these are not part of the host app and are autocreated and live until the app closes. That prevents all manner of problems caused by accessing global references that may not be valid.

Good story, thanks for sharing, Kind of impressive that it took just 4 people (2 devs) to do all that, and probably to the users it was just some new boxes and buttons, nothing so different than they were used to. Not so bad for a system that probably was +20 years old. These Delphi tales always astonishes me. Everybody knows one or a couple of cases like this. Obviously, if the company had kept a little system maintenance about let's say each 5 years, the system wouldn't have so many problems. But almost nobody does that. For sure, it paid itself hundred of times. Anyway, Better late than never. Congratulations.

This is all documented. Obviously we can tell you the answers but once you know about New, you can read the documentation to find out the rest of the details. It's really useful to know how to do that.

Hi @Stuart Clennett, it's a bug! 🙂 Thanks for spotting it. The TMARSFireDAC.InjectMacroValues and TMARSFireDAC.InjectParamValues implementations assume every TFDAdaptedDataSet actually has a Command (not nil). TFDMemTable do not have Command assigned. Workaround: if you do not need your memory table to be included as the result of Retrieve method, you can decorate it with the RESTExclude attribute: [RESTExclude] FDMemTable1: TFDMemTable; However, I just fixed this in the "develop" branch of MARS repository: https://github.com/andrea-magni/MARS/commit/b6299926671b00e75981c47a74375d9c51c529ca Another workaround would be to change your copy of TMARSFDDataModuleResource.Retrieve and change this line: if LDataSet is TFDAdaptedDataSet then to this: if (LDataSet is TFDAdaptedDataSet) and Assigned(TFDAdaptedDataSet(LDataset).Command) then The MARS.Data.FireDAC.DataModule has nothing special, it is provided as an example of use, you can copy it, change it... it is obviously the counter-part of a TMARSFDResource but there no direct deal with the specific class, just matter of the shape of its methods (types returned, GET/POST selection, ...). Thanks, Andrea

How to rework FMX? Burn it down and start fresh, with people who know how to properly structure GUI framework, would be the only proper choice. Not the viable one though.