![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
GabrielMoraru
-
Content Count
86 -
Joined
-
Last visited
-
Days Won
1
-
Android only shows the FMX logo for my app
GabrielMoraru replied to GabrielMoraru's topic in Cross-platform
Small update. I still cannot run the program from Delphi directly into the Android phone. However, I have found app's icon on the phone. If I click it, it works! So, it seems that Delphi has a problem debugging the program! _____ Hm... maybe I should try to run without debugging. -
I built a new/empty delphi fmx program with only a button on it. No code at all. I compile it and run it. I see it on the phone (android 8, delphi 12) but I only see the a white form with the FMX logo on it (red-yellow flames). I don't see the mainform itself. The main form is set to visible and stay on top, coordinates are 0,0. Somebody suggested that Android 8 has some problems with the permissions. Any ideas?
-
GroupDescendentsWith - Why 'TCustomAction' is promoted to TControl?
GabrielMoraru replied to GabrielMoraru's topic in VCL
Oh... I thought it is related somehow to the Palette. THANKS -
GroupDescendentsWith - Why 'TCustomAction' is promoted to TControl?
GabrielMoraru posted a topic in VCL
Here is a code snippet from VCL.controls.pas: initialization ... StartClassGroup(TControl); ActivateClassGroup(TControl); GroupDescendentsWith(VCL.ImgList.TCustomImageList, TControl); GroupDescendentsWith(TCustomAction, TControl); finalization ... end. Why is TCustomAction which derive from TComponent "promoted" to a TControl? -
@357mag One should consider if he really needs data bases today. In the past you had to store data in a way that was searchable. Today, for most simple applications, the data will fit into the memory. Searching in-memory data will at least thousands of times faster than searching a DB. Consider also serializing your objects to binary files! Also damn fast compared with DB.
-
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
I don't see why it wouldn't work. All the other entries support multiple paths. Plus, I have found entries like this in old files. -
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
I did a search for *.dproj and we have here 198 of these files - this means 198 packages and projects. If I change one of the 3rd party libraries then I have to adapt the rest of the 197 dproj files 😞 This is why I prefer the global Library Path. 🙂 __________ Is there something wrong with having multiple libraries into "Library path" ? Or is just a personal preference? -
How I fixed LSP (sorta) and a question
GabrielMoraru replied to Brandon Staggs's topic in Delphi IDE and APIs
I worked on multiple projects that had multi-million SLOC. The last thing that you want to do when you have such project is to add more files to it! (Especially BIG files like the ones of Delphi VCL). Even if we are in C++, the compilation time could be quite high! -
How I fixed LSP (sorta) and a question
GabrielMoraru replied to Brandon Staggs's topic in Delphi IDE and APIs
The crazy things we do for our beloved LSP 🙂 _________ I feel you. We are in the same situation - copy of vcl.grids. LSP acts strangely, exactly as you described. It is mostly unreliable or take ages to respond. Question: Why don't you let all projects use the modified Delphi files? Then you don't need the two copies. -
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
@echo on xcopy "$(PROJECTDIR)\*.dfm" "$(ProductVersion)\$(Platform)\$(Config)" /Y xcopy "$(PROJECTDIR)\*.res" "$(ProductVersion)\$(Platform)\$(Config)" /Y xcopy "$(PROJECTDIR)\*.rc" "$(ProductVersion)\$(Platform)\$(Config)" /Y echo Copy over -
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
I have seen that done. Believe me, it is not a good idea! Only nightmare will result from that. If you really want to do it, recompile your changed VCL.Forms unit once to get its DCU the and replace the original Embarcadero DCU with the yours. !!!!!!!!!!!!!!! Please open a separate topic about this !!!!!!!!!!!!!!! -
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
1. Since the precompiled DCUs of the libraries should be located via "Library Path" (not via "Search Path") the option to edit DCC_ResourcePath should be a global option not a per-project option. I think your request does not make that clear. 🙂 2. Is there a way to vote for that feature request? In the past we had that possibility. Now it is gone. -
About the compiler (not) finding the DFM files
GabrielMoraru replied to GabrielMoraru's topic in Delphi IDE and APIs
> "I just add the "library" forms to the project that needs them" a) Won't this break the second rule: "2. Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time"? b) Plus, this way you have to maintain the files twice. If you add/remove a form from your package, you need to manually add/remove it also from all DPR files that use that form. If so, then copying the forms to the binary output (DCU) folder of the library via a post-build script it is still the best "hack". > "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" I will try that! Thanks! -
Your call stack does not indicate that the call is going through an ide expert. Additionally you don't need to really uninstall the experts. For some of them (but not for gexpoerts) you can temporary disable their package directly from the IDE. Not even need to restart the IDE. Or use \CnPack\CnManageWiz.exe to manage your installed IDE experts (IDE restart required).
-
So, I have a program that uses the precompiled units of a library. This: Allows me to keep the Search Paths totally empty (as they should be) Prevents the compiler from keep recompiling the files of the library unnecessarily, saving compilation time. But if the library has DFM files, the compiler will throw that famous "where are my DFM files?" error message. The "solution" (well, it is not a real solution, but rather a dirty trick) is to (manually or by script) copy the DFM files to the DCU folder of that library. Four output DCU paths, four copies. What a nasty "solution"... So, did anyone found a more elegant way to solve this? I see in some old DProj files an entry called <DCC_ResourcePath>, but there is no page in "Project options" or in IDE's "Tools -> Options" to set that path.