Current filter:
                                You should refresh the page.
                                  • We build our software suite out of a collection of packages with components that can be used by the different applications. One such package contains forms and frames that can be created at run-time and embedded in the software. We decided to change the main form for one of the applications (which is also in one of the design-time packages) to use TheBezier as skin. This forced us to add a reference to dxSkinTheBezierRS26.dcp to the package. Once this is done, however, TheBezier can no longer be selected (it's no longer listed as an available skin, not even through Modify Project Skin Options) as long as our design-time package is installed in the IDE. Removing the reference to the DCP file for the skin causes another series of issues (having the skin in multiple packages).

                                    Are there limitations to working with skins in forms/frames inside design-time packages? What would be the best way to solve this issue?

                                Show all comments
                                • Mikhail (DevExpress Support) 08.07.2019


                                  It is difficult to say for sure why this happens. We will discuss your situation.

                                • Mikhail (DevExpress Support) 08.08.2019


                                  We tried to replicate the issue on our side, but failed. It seems your scenario is more complex. Perhaps, you work with a skin in your application.
                                  Nevertheless, would you please provide us with a detailed step-by-step instruction on how to replicate the issue on our side from scratch? I hope this will help us determine the cause of the issue.

                                • P.A. Jimenez 08.08.2019


                                  I have tried the following steps to reproduce the first issue:

                                  - Create a run-time package with a form that uses a skin controller and select TheBezier
                                  - Build the run-time package
                                  - Create a design-time package with a unit that includes (uses) the form and references the run-time package in its "requires"
                                  - Install the design-time package

                                  I get the following error message:

                                  Cannot load package 'RunTimePackage'. It contains unit 'dxSkinTheBezier', which is also contained in package 'dxSkinTheBezierRS26'.

                                  - Now add dxSkinTheBezierRS26.dcp to the run-time package and rebuild
                                  - Install the design-time package

                                  Delphi is now happy to install the design-time package.

                                  The second issue is the one I cannot reproduce with the test. We do use a custom skin package which we use to load at run-time the actual skin, so it can be used in all applications while keeping the total size of the suite smaller than baking the whole skin in each application. I tried including this package and enabling the custom skin along with TheBezier, but it works just fine.

                                  No idea then what's causing the second issue. All I can think of at the moment is fully removing the custom skin and all references to it, in case it's interfering somehow. I'll let you know if it solves the issue.

                                • P.A. Jimenez 08.09.2019

                                  I have fully removed our custom skin from every possible file, including pas, dfm and skincfg. All software has been fully rebuilt with the skin package being left out, clean and uninstalled. The problem still remains.

                                  What's rather curious is that if I start Delphi with the packages uninstalled, install them and open the main form , then all is well. If I close Delphi and open it again (in which case the packages are already installed) and open the main form again, the skin no longer works: the form shows up with another skin applied to it. Although TheBezier still shows up as active skin in the skin controller, it won't show up in the drop down anymore. It actually fully disappears from the available skins. I even moved the main form from the package into the application's project, but there are still other forms and frames in there using the skin.

                                  Is there anything I could check locally to pinpoint the issue?

                                • P.A. Jimenez 08.09.2019

                                  I have gone even further by building the package for TheBezier with debug information and using it to debug Delphi itself. The test project I created works fine, and I do get to the different breakpoints I set (RegisterPainters, UnregisterPainters and initialization). Working with our actual project, I see that the package gets loaded, but no single breakpoint is reached. I would expect at the very least the one in initialization to work.

                                  There's an access violation in this case, but it happens in the parser thread of the IDE itself. It has no relation to loading the package or not.

                                  It does of course make sense that if the skin package doesn't get initialized, then it won't work properly, even if it gets loaded. It should be happening in System.InitUnits, yet there's nothing suggesting it's failing halfway through it, thus never reaching the skin unit.

                                  I'm using version 19.1.4 now as well.

                                • Mikhail (DevExpress Support) 08.09.2019

                                  It is difficult to say for sure why this happens without a sample project. Would you please provide us with your package and a test project, so that we will be able to replicate the issue?

                                • P.A. Jimenez 08.09.2019

                                  Unfortunately it's not practical for us to provide you with our package because it depends on basically every other package we have. It's a package where all the frames and forms that make use of the rest of the system come together

                                  I have managed, however, to find the reason the package is not initialized: when TdxSkinsPackageManager.TryGetPackageInfo calls GetModuleHandle, it returns a valid handle because the bpl is already loaded. For that reason, the skin does not get registered. Even though the package has been loaded, it never gets initialized. This happens when our packages are already installed.

                                  I also placed a conditional breakpoint in System.SysUtils.LoadPac kage, confirming that as long as our packages are installed, the skin never goes through this method.

                                  In the events log I do see TheBezier being loaded while Delphi is loading some of our other run-time packages. What's not clear is which package is doing this in such a way that LoadPackage gets skipped.

                                  It'll have to wait until next week before I can continue looking into this issue.

                                  Do you have any recommendation to be able to catch the culprit? I tried looking into some dependencies of different bpl files, but none depends on the skin. Setting a breakpoint inside LoadLibrary is a last resort, and I'm still not sure if it will make things clearer.

                                • P.A. Jimenez 08.12.2019

                                  Setting a breakpoint inside LoadLibrary didn't help. I thought it may have to do with the order in which packages are loaded (our packages use a prefix that comes before those of DevExpress), but I couldn't reproduce the issue that way. I then proceeded to turn run-time packages into "designtime and runtime" packages on all dependencies, but none of them would cause the skin to be loaded.

                                  The very last step that seems to workaround the issue was to turn the design-time package that actually uses the skin into a "designtime and runtime" package, even if it does not register anything.

                                  It remains unclear why it happens and cannot be reproduced, but at least we can continue developing.

                                • Mikhail (DevExpress Support) 08.12.2019

                                  We tried to replicate the issue on our side, but failed. It seems your scenario is more complex and thus we require a step-by-step instruction on how to replicate the issue on our side.

                                  From what I gather, you are unable to reproduce the problem with a very small and simple test project. Am I right?

                                • P.A. Jimenez 08.12.2019

                                  That's right. All attempts to reproduce the issue with a simple test project failed. There it just works. It may end up being a single file in the package doing something that causes the skin to load prematurely and without initialization. It didn't go through the breakpoint inside LoadLibrary, though. Being able to break the moment the skin is loaded by our package may be the key to solve the issue. The question would then be why it works fine when the package is turned into a design-time and run-time package.

                                  Delphi seems to have this functionality already (Run -> Add Breakpoint -> Module Load Breakpoint). Time to check if it works with BPL files.

                                • P.A. Jimenez 08.13.2019

                                  "Module Load Breakpoint" works, but it just shows that the skin gets automatically loaded as a dependency by the OS.

                                  I decided to compare the dependencies of our packages to those of the test project, and there's an interesting difference (I use Dependencies since Dependency Walker no longer works).

                                  In the test project, both the run-time and design-time packages have dxSkinTheBezierRS26.bpl as a dependency, with the design-time package depending on the run-time package as well.

                                  In our project only the run-time package has a dependency on dxSkinTheBezierRS26.bpl. The design-time package has a dependency on the run-time package, though.

                                  My guess is that the none of the files used by the design-time package makes use of dxSkinTheBezier, therefore skipping the dependency on dxSkinTheBezierRS26.bpl. Adding dxSkinTheBezier to the uses clause of a file in the design-time package forces the dependency, and the problem goes away.

                                  With that knowledge in hand I finally managed to replicate the issue with the small test project. Here are the steps:

                                  * Create a run-time package (I used the name bRunTimePackage)
                                  * Add a form to the run-time package, drop a skin controller on it and choose TheBezier
                                  * Add a unit to the run-time package just to declare a new component (I used TMyButton = class(Button);)
                                  * Create a design-time package (I used the name aDesignTimePackage)
                                  * Add a unit to the design-time package and use it to register the component (do not reference the form)
                                  * Add bRunTimePackage to the requires of aDesignTimePackage
                                  * Build both packages and install the design-time package
                                  * Restart Delphi
                                  * Open the form inside the run-time package
                                  * Behold the disappearance of TheBezier

                                  It does not seem to be a DevExpress problem but instead a shortcoming of working with packages in Delphi (I also saw somewhere that Microsoft changed something in the way modules are loaded in a previous version of Windows 10 that was causing problems with Delphi packages).

                                • Mikhail (DevExpress Support) 08.13.2019

                                  Would you please send us your small test project for research?

                                • P.A. Jimenez 08.13.2019

                                  Small test project attached.

                                • Mikhail (DevExpress Support) 08.14.2019


                                  Thank you for the project. We will examine it.

                                • Mikhail (DevExpress Support) 08.15.2019


                                  I'm unable to replicate the problem with your example. Here are the actions I tried:

                                  1. Rebuilt your packages;
                                  2. Installed the aDesignTimePackage package to my IDE;
                                  3. Restarted the IDE;
                                  4. After the IDE was restarted, I opened the ProjectGroup.groupproj file there and opened the PackageForm form.
                                  5. Our Ribbon in the PackageForm form were skinned.

                                  Have I missed anything?

                                • P.A. Jimenez 08.15.2019


                                  I tried it again here, and it indeed works as it should. However, if I start Delphi in order to debug another instance of Delphi, the debugged instance reproduces the issue (the skin jumps to a blue skin and TheBezier disappears). With our packages it just happens (no other Delphi instance needed).

                                  Since I was debugging installed DevExpress packages to try to pinpoint the issue, I was running the first instance of Delphi (the one to debug the other one) in administrator mode, so it could create and modify files inside C:\Program Files (x86).

                                  I'm once again clueless as to why our package does it all by itself. The dependencies seemed to be the right cause, since it was also what solved the issue for us. I checked again, and the small test project does indeed create the dependencies the way it is intended to.

                                  I tried running Delphi through WinDbg, and I couldn't reproduce the issue. Then I tried again debugging Delphi with Delphi (without administrator mode this time), and I couldn't reproduce it either.

                                  All I noticed when comparing the event log of Delphi while running the other Delphi instance as administrator and then as user is that the test package gets loaded a bit earlier in the administrator mode scenario.

                                  Can you at least manage to reproduce the issue by debugging Delphi with Delphi in administrator mode? The only other package we have installed in Delphi is madExcept .

                                • Mikhail (DevExpress Support) 08.16.2019

                                  I'm not sure that I understand how to replicate the issue on our side.
                                  Would you please provide us with a video that demonstrates required steps. Also, in this case, we will be able to see how the "problematic" behavior looks in your project.

                                • P.A. Jimenez 08.19.2019

                                  See attached video.

                                • Mikhail (DevExpress Support) 08.19.2019

                                  Thank you for the video. We will examine it.

                                • Paulo (DevExpress Support) 08.26.2019


                                  Unfortunately we didn't manage to reproduce the issue. It seems that we are doing exactly what you are doing in your video, but the skin is still there. It does not disappear.
                                  However, we have an idea about why this may happen on your machine. Please help us check it:

                                  1. Download the attached dxSkinsReg.pas file.
                                  2. Replace our default dxSkinsReg.pas file with it.
                                  3. Run our Installer in **Recompile ** mode to rebuild all packages.
                                  4. Try to reproduce the problem once again.

                                  I am looking forward to your research results. Thanks in advance.

                                • P.A. Jimenez 08.27.2019

                                  The problem still occurs using the new file.

                                • Paulo (DevExpress Support) 08.27.2019

                                  Thanks. To my regret, we are running out of ideas.
                                  Please go to the main menu of the IDE that you are using to debug your packages and select View->Debug Windows->Event Log. Then reproduce the problem. Do you see the Module Unload message that unloads your TheBezier package in that Event Log window? If yes, what are its details?

                                • P.A. Jimenez 08.27.2019

                                  See attached file for the logs.

                                  log1.txt is the log of the failing situation (TheBezier used by the run-time package but not by the design-time package).

                                  log2.txt is the log of the working situation (TheBezier used both by the run-time and design-time packages).

                                  In both situations TheBezier follows the sequence Load -> Unload -> Load, just like any other package. The internal difference is that in log1.txt Delphi fails to catch the loading of the package in order to call the initialization sections.

                                  The biggest difference I notice is the order of Load -> Unload -> Load between the run-time package and TheBezier. In log1.txt they happen right after each other for both the skin and the run-time package. In log2.txt they are a bit intermingled. This may be caused by using the skin in de design-time package as well.

                                  I also ran out of ideas. Even the small test project requires a very specific situation to trigger the issue. What's important is that using the skin in the design-time package solves it, and it also seems to be a rather obscure situation no one else is experiencing. Given what happens (actually, what doesn't happen), the issue should be for Embarcadero to look at, which may just as well be hopeless.

                                  Thanks for all the time and effort you've put into it, but it seems the best solution is just to add the skin to the uses clause of a file in the design-time package and move on (assuming anyone manages to experience the same issue, that is).

                                0 Solutions

                                Creation Date Importance Sort by