In my Firemonkey multi device project the IDE keeps adding the unit "FireDAC.VCLUI.Wait" to my uses in a data module of my project.
This unit keeps me from building the project, because it can't resolve the name in Android or iOS. The strange thing is that it previously didn't do this and I haven't added/changed anything to this data module.
I know some component add units to the uses but as I said it's a firemonkey project not a VCL project so it shouldn't add this.
How can I keep the IDE from adding this unit?
Place a IFDGUIxWaitCursor component on your data module and set its Provider property to 'FMX' (FireMonkey).
Remove that unit from the uses section, so the IDE will now set the one corresponding to Firemonkey instead of VCL.
Note: If the Provider property changes its value, then developers need
to delete the implementation units for the old Provider value from the
uses sections. For example, switching from 'Forms' to 'FMX' requires
to delete the TFDGUIxFormsXxx units.
You can set the "Provider" property to "Console", if you compile it for Linux.
Related
We converted a large application suite from another database layer to FireDAC. The (Win32) programs currently do not implement a FDGuixWaitCursor, and the legacy code has calls to 'push', change and 'pop' the screen cursor.
Should I add FDGuixWaitCursor to my 'base' datamodule for any important/technical reason?
The documentation Preparing a FireDAC Application for Run Time does not really answer that.
Not necessarily. The TFDGUIxWaitCursor component makes sense to use if you wanted to setup the cursor, handle cursor changing events or include the project type implementation by setting up the Provider property. Nothing more at this time (Delphi 10.2.3 Tokyo).
If you don't need any of this, you can just include FireDAC.VCLUI.Wait module into a VCL project, FireDAC.FMXUI.Wait into an FMX project, or FireDAC.ConsoleUI.Wait into a console project.
It's worth adding that FireDAC includes all the necessary modules automatically for its design time created components (so one of them is most likely included in your data module).
When i create a new service, then this service will have a main datamodule (DM), and when i add this service to an already existing app, then delphi automatically add to the dpr (in the uses clauses) of this app the unit of the datamodule:
uses ...
...
myService_mainunit;
why ? it's also make after not possible to compile under IOS ...
The IDE has absolutely no idea what your intentions are. It has no clue that you only want to use this for Android, regardless of if it's Android-specific code or not. You have to write the code which tells it this, such as using conditionals.
When you created a new Android Service, the IDE set up a pre-made template for you. This template just happens to use a Data Module to do its work. But when you add the Data Module to a project, the IDE simply does not know why you want to add it. It's just doing its job, it does this for any and every unit you add to your project, regardless of what that unit's purpose is. In fact, there is no such thing as adding a unit to your project and not being in the DPR uses.
"it's also make after not possible to compile under IOS"
Again, this is easily resolved by wrapping platform conditionals around it. Of course, the IDE "takes control" of the DPR file, so perhaps not that easily, as the IDE could malform your code. It is however very possible by not including this Data Module in your project, but place it in a location where your project can find it.
As the title suggest, I can't find that unit.
Is there an equivalent?
I am trying to port a unit from VCL to Firemonkey which contains OleServer in its uses clause, but I can't find any information on Embarcaderos website regarding this problem.
I have also tried to Google it, but no success.
Where can I find TOleServer and/or its unit OleServer that is compatible with Firemonkey?
Or how can I implement that unit in my Firemonkey project?
Hi i have the same problèm before and i made change in OleServer
Copy Vcl.OleSever to your project and rename it to FMX.OleServer
in implementation section do change like this:
implementation
uses
FMX.Controls;
resourcestring
sNoRunningObject = 'Unable to retrieve a pointer to a running object registered with OLE for %s/%s';
at the initialization section change to FMX.Controls.TControl
initialization
GroupDescendentsWith(TOleServer, FMX.Controls.TControl);
end.
Finally rename VCL.OleServer to FMX.OleServer in your imported library unit
Indeed the main issue with compiling TLB (typelibrary) units for COM/OLE Servers seems to be some unit renaming that has occured. Ideally the Delphi IDE should detect this automatically and fix it.
Based on Doug Rudd's comment above I fixed my "uses OleServer" to "uses Vcl.OleServer" in my TLB unit.
Since there's a "source" folder under Delphi installation folder even for the Pro version now (at least at 10.2.2 Tokyo version that I'm currently using), I could also easily spot (using GrepWin free tool) where the "EmptyParam" that was causing my TLB to not compile had gone. It is under System.Variants unit that one also needs to use in their TLB (before it was in System so you didn't need to use some unit for it).
Guess I could have imported the COM/OLE Server again to make new TLB import unit, but since it was hand-ended (to remove using of "Graphics", "StdVcl" and "OleCtrls" units that were bloating the executable size in older versions of Delphi) and that hand-edited imported TLB used to work fine for a command-line application, I didn't have any reason to reimport the Type Library.
You can see the changes I did to make my XSLer tool work with the latest Delphi at https://github.com/Zoomicon/tranXform/commit/e99f42049b8a4c1534d9edb78ed5e6493e6e5786. That XSLer command-line tool is using MSXML (Microsoft XML) automation server.
I am writing a localization application in which i am reading the DFM information from the application resource through EnumResourceNames API call.
However, the function returns me a name of the form for which the DFM is associated. I tried getting the class from the FindClass, but since this whole operation is coded in a package, the FindClass fails. RegisterClass routine is called from the exe's intialization section.
FindClass works fine when called from within the code written in the exe project. So, i have developed my own registration framework wherein i add all the Form classes, but this is real pain as i need to add the unit of the form and then pass the form class to the RegisterClass routine.
I was hoping if anyone can provide a simple solution of getting all the classes that are in the executable from which the instance of the object can be created by searching the classname.
BTW I am using Delphi 6 Update 2.
Thanks
Rahul W
If the application is calling RegisterClass() and the package is calling FindClass() (or vice versa), that will only work if both the package and the application are compiled with Runtime Packages enabled so they share a single instance of the RTL (which means you have to deploy the RTL and VCL packages alongside your application and package). Otherwise, your application and package will have their own local copies of the RTL instead. In order to share classes in that situation, one project will have to export extra functions that the other project can call when needed to register its local classes in the other project's local class list.
As for detecting the available classes dynamically, that is not possible in D6. The RTTI system did not gain enough detailed information to perform that kind of enumeration until D2010.
I am working on a component in Delphi 7 and Delphi 2006, where I am using a unit which I need to add to the .dpr file of the project on which the component is dropped automatically.
Like the way Eureka Log automatically adds the unit 'ExceptionLog' to the project file:
Can anyone tell me how to programmatically add a unit to the project file when I drop my component on any form in the project?
You most likely have to use the Open Tools API for that.
Also it might require to write a TSelectionEditor for your component to trigger the adding of the unit (I would try the RequiresUnit method).
While there is an easy way to just add a unit to the active project (code below) this just works for the active project which might not be the project the form belongs to you are adding the component to. Also it adds the unit at the end of the uses clause.
uses
ToolsAPI;
var
currentProject: IOTAProject;
begin
currentProject := GetActiveProject();
currentProject.AddFile('MyUnit.pas', True);
You can check the GExperts source code because it contains a class (TUsesManager) that can parse units and modify the uses clause.
Odd.
I used to set my default dpr to contain next to nothing as a result my toolbox was very empty. So if it was in my toolbox it was in the dpr - what are you having problems with - normally if its in the toolbox, its already in the dpr.
go Project > Eurekalog Options and disable Eurekalog.