PeterBelow

Does something useful happen if you click on a ">" on the right hand side or select a different platform as target?

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.

One thing too keep in mind is the fact that form variables created by the IDE do not get assigned any form reference if the unit is part of a package and the form is also not autocreated. If you create the form in code it is your responsibility to assign the created form reference to the variable if you intend to use it (which is a bad idea in the first place IMO).

That was a looong time ago and I've not done any serious programming in years. Actually I newer participated in a beta due to lack of time and spare hardware (installing a beta on my production PC was just too risky). And your memory is correct, I did start on the old Compuserve BPASCAL forum before Delphi was even an idea in Anders' brain 8-). Those were the days, acoustic couplers to connect via phone line, later 9600 baud modems, Turbo Pascal, later for Windows with OWL... lots of fun. Just a bit depressing that quite a few of the old crew have already passed away...

Got an invitation last Friday, am on regular subscription.

Are you aware that the IDE uses different layouts for design and debugging modes? Just arrange the IDE once as you want it to show while debugging, save this layout under a name of your choice, and define it as the debug layout to use. See https://docwiki.embarcadero.com/RADStudio/Athens/en/Desktop_and_Layout

Probably nothing :). The default setting for range checking changed to "on" and the Lockbox version in GetIt may not reflect that yet. Try to use the latest version from github instead: https://github.com/TurboPack/LockBox3

Well, you have to make sure the program is build with debug information (check the project options) and also check the IDE debugger settings in the Tools -> Options dialog, under Debugger -> Embarcadero Debuggers. There you find two lists for exceptions the debugger was told to ignore.

You usually get these "different version" errors if you have several versions of Delphi/RADStudio installed and try to move an older project to the newer version. Some path setting in the project options then may refer to a folder holding dcus from the older Delphi version and that results in this error when compiling. So check the project options, or delete the project's DPROJ file and open the corresponding DPR in the IDE to make it generate a new DPROJ. Oh, and the lib subfolders hold the dcus needed if you build a program for either the Win32 or Win64 target platform, they have nothing to do with the OS version you are running on.

Check the blog for the patch, I think it mentions that you have to redeploy the new paserver executable manually.

Oh, I forgot: we have C++Builder section in this forum, perhaps someone there has the old demos available.

For RADStudio versions before 10 the demos were part of the installation package, if memory serves, If you have not done so and are desparate enough 8-) look what is available for you on my.embarcadero.com, download older ISOs and check their content for the demos.

Check the Emba Github repository.

Try to add a class constructor and destructor to your custom control, like class constructor TMyTabControl.Create; begin TCustomStyleEngine.RegisterStyleHook(TMyTabControl, TTabControlStyleHook); end; class destructor TMyTabControl.Destroy; begin TCustomStyleEngine.UnRegisterStyleHook(TMyTabControl, TTabControlStyleHook); end; Of course you need to use your component class name instead of TMyTabControl.

It has worked this way for many Windows versions: if the control with focus is not editable a shortcut will be triggered if the matching character key is pressed even if Alt is not held down. The VCL just adheres to that Microsoft UI design choice. You can add a handler for the parent form's OnShortcut event (or override the virtual IsShortcut method) to change the default behaviour. If you want to learn more about key handling in a VCL app here is a link to an old article of mine on the subject (Delphi 7 vintage).

The error message indicates that the compiler is not evaluating the right-hand side expression as you expect. Instead of converting V to a string and concatenating the result to the string literal it is trying to convert the literal to a variant containing a TBcd, adding the two numbers, and then convert the result to a string. If you have a masochistic streak put a breakpoint on the statement, run to it, call up the disassembly view and F7 through the generated code (debug dcus need to be enabled). I would not call that a bug, just unexpected behaviour. But as you know, in programming the compiler is always right... 🙂

OK, I would not do it this way, but your problem is probably a missing FormType node in the DPROJ file. Look for nodes "DCCReference Include" and see how a "uninherited" datamodule is defined there. Compare with one of your derived datamodules.

To make the inheritance work for designer classes like a data module your TBaseDataModule has to have a DFM-file, even if it is practically empty, but it must contain a valid Name property. The simplest way to get one is to create a new data module in the IDE and change its Name property to BaseDataModule, then save the unit under the name you want. You can now change the inheritance of your TMainDataModule in the editor, but you also have to switch the designer for that module to the dfm view and there change the first "object" keyword to "inherited". And make sure your TBaseDatamodule is not in the list of autocreated items! You can delete the BaseDataModule variable the IDE created for you, it is not needed.

Microsoft has released several versions of the richedit control over the decades, TRichedit in the current Delphi version (since 11.0 if memory serves) is based on version 4 (the latest and most feature-rich). The Jedi version may be based on an older version. The divers versions are implemented in separate DLLs with different names and use different window class names, so they can coexist on a given Windows system. Different versions may explain the behaviour you see.

Won't the MS Store sign the package for you when you upload it? I dimly remember some mention about this (also for Google and Apple app stores) in a webinar i watched recently.

Is the BiDiMode property set to true on all controls in question? Also look at the methods in the see also section at the bottom of the page linked to for BiDiMode, may be important if you test on a non-hebrew locale.

I just add the "library" foms to the project that needs them, this way the required path is in the dpr file uses clause. Btw.: I think this DCC_RessourcePath is for the resource compiler and you can set it under that node in the Options dialog. Never needed that myself, though.

Then why don't you delegate the hint showing to a task running in a secondary thread? The task can wait for a short interval and if it is cancelled before that interval has elepsed the hint will not be shown at all...

The answer is no since the update would have to be triggered somewhere from inside the work code. But you can create and show a window from a secondary thread, it is just a bit cumbersome to do since the visual part of the VCL is not thread-safe. The secondary thread needs a message loop that will process all messages for the window, including timers and paint messages. The simplest way to get that loop is to show the window modally. And the safest way to do such stuff is to not use a Delphi form but do it all the API way (hence the cumbersome part above 8-)). If you want to use a Delphi form the important points to mind are: Do not autocreate the form! Create the form inside the Execute method of the secondary thread, using Nil as owner. Use a try finally block to make sure the form is destroyed. Use a field of the thread class to store the form reference. ShowModal the form. Add a public method to the thread class the main thread can call to get the form to close once the work is done. The method should set the form's ModalResult to mrCancel to allow the modal loop to exit normally.

Try to set the KeyValue property to the ID you want to look up.