I have inherited an application that was built in Delphi, using clx components (TcxMaskEdit, TcxCurrencyEdit). I cannot open this application because I lack the clx components in my copy of Delphi. If I ignore the warning messages, the application opens without those components on the forms and the Win32 library disappears. I cannot get these components because they are no longer carried by the original developer. So, this leaves me with two options: either find a way to get the clx components, or convert them to vcl. The application has had so many man hours devoted to it and is so business critical that it cannot be easily re-written or replaced. So, my question is: how can I convert the clx components to vcl or otherwise obtain these deprecated components? Or is there something here that I'm missing?
TcxMaskEdit and TCxCurrencyEdit are not CLX controls. They're part of the older Developer Express components (not sure if they're still around or not). In order to open your project, you'll need to get a copy of whatever version your application used. You'll need to ask the old developer what that was, or contact DevEx support and see if they can help you.
(The CLX components have the same name as their VCL counterparts. The only difference is the unit names in the uses clause of your source; the VCL Dialogs unit is replaced by QDialogs, Forms becomes QForms, and so forth. Switching from CLX to VCL is as easy as searching for any unit starting with Q, and removing that single letter if there's a corresponding VCL unit, and then rebuilding your app.)
Related
Considering the grief we've been having with VCL styles in Delphi 10.2 Tokyo around its use in dynamic link libraries and how it affects the built-in help viewer, as well as a number of negative comments from the community about VCL styles in general, is there another way that we can colour the application windows as in the examples below:
This feature has been part of the application since it's inception in 2001 and it vital for a number of our largest clients, as they actually maintain separate accounts for their subsidiaries and use the colours as an indication of which company they are working with.
Here are the third party skinning products I found so far:
TMS Skin Factory. This has been discontinued.
VCL Styles Utils. This extends VCL Styles and the issues with 10.2
Tokyo remain.
VCLSkin. This has not been updated since XE6.
Almediadev. Just like with DevExpress, we would need to replace all the standard controls with their specific versions in order to apply their skins.
I will update my answer as I find more.
Unfortunately, any answer where we have to replace the components offered by Vcl.StdCtrls or Vcl.ComCtrls with versions specific to the third party package is not going to work. We have 2500 TButtons alone across all the programs in the suite.
EDIT: In the end, we found an answer, or workaround, to the System Exception problem that had us looking at alternatives to VCL Styles in the first place:
Using VCL Styles in a DLL causes System Exception in 10.2 Tokyo
Just upgraded from Delphi XE to Tokyo, and was hoping for some updated IDE features.
One nice to have feature would be automatically providing options to add a unit to the uses clause. For example, if you reference something in code that isn't in a uses, it would be nice if the IDE prompted you to add the related unit(s).
For example, keeping it simple, in IntelliJ, you might declare a Button, but not yet have added the associated Library to the Import clause.
When this happens, the offending line is highlighted (just like in Delphi), but the IDE will let you add the necessary library with an Alt-Enter. If there are multiple libraries (it knows about it) it will prompt you for the one you want.
Anything like this for Delphi?
Delphi 2007 and later versions support this for most types that it knows about (in the search or library path). (It may have been available in D2005/2006; I don't have them installed anywhere now to check. I know it was not in Delphi 7.)
Put in the type, and use the Refactor menu (Refactor->Find Unit) or press Ctrl+Shift+A.
Here's an example:
It's not 100% effective, but it's a vast improvement over the old way.
(And yes, I know about TArray<string>, before someone chimes in. I just grabbed a quick type that I knew wouldn't be in the default VCL form uses clause for an example.)
Following on from my previous questions (Delphi 6 TDateTimePicker Windows Visual Theme support via Manifest), we are updating a legacy application developed in Delphi 6 to support Windows Visual Themes (to freshen up the UI). We have included a Manifest and now also Mike Lischke's Windows XP Theme Manager (WXPTM) components, as per previous recommendations.
We can see three components on a new XP tab (palette) in Delphi, have included the path to the library's in our project and dropped the components onto one of the forms. The recompiled EXE is now displaying controls differently from prior to including WXPTM and it seems to have fixed a number of issues, so I am fairly certain (and hope) we have implemented WXPTM correctly.
However, we have some third-party component controls that are descendants of the standard ones, which we thought (hoped) would simply inherit from the replacement/updated controls in WXPTM. Unfortunately, it appears they do not, unless we have missed something out in the WXPTM implementation. Therefore, is it possible to make third-party controls inherit from the updated standard controls in WXPTM? Any tips, tricks, suggestions or advice to point us in the right direction would be greatly appreciated.
Ok, so I downloaded a .zip file of all different kinds of examples from embarcadero... the way the buttons look and among other things are completely different from when I just create an application within my Delphi 7. I believe these examples were made for or made at a new time... because the button look way different from the way the button when I put them on my application. the buttons from the example look very modern and sleek and have mouse over effects (This applies for all the examples..its not a custom component ) I was wondering I can get this effect in my own applications within Delphi 7.. I can do this by opening one of the examples and just erasing all the code... but that's not what im trying to do..im wondering how I can accomplish these styles.. how come the examples have these nice looking buttons and such..but when I make an app within D7 its much older looking and such..
I apologize if my question is hard to understand.. and I appreciate any help on this.
Thank you in advance.. I appreciate it.
If I understand your question correctly, you're asking about the native control appearance changes that were added by the addition of Windows Themes in Windows XP.
Delphi 7 supported themes by use of the XPManifest component, which does nothing but add a manifest to your application which tells Windows your app is theme-aware and therefore it should load a more recent version of the common controls library. You can find the XPManifest component in the VCL component palette on the Win32 tab, or simply add the XPMan.pas unit to your uses clause. Note that the themed drawing does not work for all controls (grids, for instance, are not drawn using themes, and IIRC neither is TSpeedButton - it's been a long time since I used D7, so I'm not sure exactly what is and isn't supported, but the support is limited).
Starting with Delphi 2007, there is built-in support for Windows Themes, which is available by default in new projects. It can also be enabled in older projects using a checkbox in the Project->Options->Application dialog.
(Of course the real answer is that if you want your app to have the features included in modern versions of Windows, you should upgrade from your Windows-95 era version of Delphi to one that is more recent.)
Is it good idea to put Forms that have complete functionality in dll.
And main app will invoke dll function that returns form object.
The accepted way to do this in Delphi is to use packages rather than DLLs.
Packages are essentially DLLs but with Delphi specific capabilities that allow VCL objects to be used across package boundaries.
Trying to do this with DLLs will lead to a variety of problems that packages deal with. One downside of packages is that all modules must be compiled with the same version of Delphi. But if you are wanting to share objects across module boundaries then you would face the same restriction if you used DLLs.
The Delphi documentation has extensive coverage of packages.
Having said all that, I would add that if you can put all your code into a single module (.exe or .dll) then it does make life a lot simpler.
Adding to the answers about using packages:
Packages can only be used if both, the main app and all dlls (plugins) are written in Delphi and are written using the same version of Delphi
DLLs can be written in any programming language that can create them and can be used by any program regardless of the programming language
So, using dlls rather than packages does make sense.
Regarding the actual question: Yes, it is possible to put forms into dlls and they usually work fine. Just make sure that you do not pass them around because they are only valid objects within the context of the dll. You will experience the odd problem with forms losing focus or coming up behind other forms. This can usually be fixed by passing a window handle from the main executable to the dll which is then used as the parent for the form.
Also note: TObject of your dll is different from TObject of your application. The same applies to other commonly used classes and variables like (Forms.)Application.
I have done it and it was a pain in the lower back but it was not impossible. The main program was written in Visual Basic 6, some modules were written in Delphi 6, others were written in Delphi 7 and Delphi 2007.
Conclusion: If you are sure you will never use something different than Delphi for your app and for your dlls (plugins) and are willing to always recompile everything when you switch Delphi versions, you should use packages. Otherwise it might be better to use regular dlls. (And are you sure you will always be the only person writing these dlls? Maybe at some time there will be a 3rd party developer for one of the dlls who does not own the Delphi version he needs.)
IMO this is sometimes a very good idea and the only way to go - for the reasons others have mentioned, I'm not a fan of packages, and am very comfortable with DLL's. I am currently adding functionality to an app written in Delphi 5 using Delphi XE - it was either use DLL's or write in D5 - of course I opted for the former: D5 app calls DLL's written in XE that contain all the latest and greatest features. (The first projects I did in Delphi were done via the old Borland Paradox - Paradox app invoked DLL's written in Delphi 1!)
But, I don't send the form or module from the DLL back to the main app - I just send the DLL module a structure containing what it needs to know to do its work, and when it's done and the DLL's form closes, it cleans up and then and returns a numerical code or structure back to caller indicating success, failure etc ( old fashioned but very effective).
Passing the form instance from the DLL back to your main app across the DLL threshhold can be problematic - note #dummzeuch's excellent answer above with some good tips on how to negotiate some of those problems should you decide that is your only solution.
+1 for everything that David Heffernan says.
Strategically, you really only need to implement forms (or other functionality) in external files if you're implementing a plug in system.
If you're going to allow plugins to be authored in any language, then DLL's are the only way to go.
If your plugin system will be restricted to developers with the same version of Delphi (same team perhaps?) then go with BPL's. The additional drawback of Delphi packages, from my perspective, is the need to deploy the VCL BPL's with your app, which are always more Mb than a single compiled module.
If on the other hand you want to write a modular system, you can still do that by implementing loose coupling & "plugin" techniques within your code and still compile to a single module.
If you put a form in a normal dll the form won't be able to intercept the TAB or arrow keys. I have been told that this is due to the OnKeyDown not be passed through.