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).
Related
Is it possible to automate setting the Option Set file reference programmatically when creating a new Delphi project using the IOTAProjectOptions respectively IOTAProjectOptionsConfigurations interface1?
Or can I do that using any of the other OTAPI IDE services2?
I'm currently using the RAD Studio Delphi 10 Seattle IDE. Though, if newer OTAPI versions would support that feature, I'd still like to know about that.
I couldn't find any appropriate property or function, that seems to do that action in my current ToolsAPI.pas.
I want to achieve the same as choosing Apply Option Set -> Reference at the root project configurations root node in the IDE's project manager view:
Hypothetically I'm looking for some functionality like
procedure IOTAProjectOptionsConfigurations.BaseConfiguration.ApplyOptionSetReference
(const optSetFilePath : string);
A bit more background:
I'm currently developing legacy project wizards for our company wide Delphi project settings. I already have a working IOTAProjectCreator implementation that also manipulates the .dproj MSBuild XML file after it was generated and saved by the IDE. I'm just adding some conditional Import elements there.
Now we also want to use a Options Set file that is stored at a central repository. I know and studied the differences done in the .dproj XML, after that action was applied using the GUI, but there's a non negligible amount of logic going on (regarding dependencies and such), and I'm refraining to (re-)implement that logic via plain XML file manipulations. Not to mention that the necessary logic is prone to be changed with future versions of the IDE.
1)I'm trying to use that in the context of a IOTAProjectCreator implementation, with the definition of the procedure SetInitialProjectOptions(NewProject : IOTAProject); function.
2)It's a shame that these features are documented so poorly.
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.
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.
I tried to copy and paste a component from one data module into another in Delphi XE2. The component was a Fast Report data source link component. The data module was brand new, just created that second, in XE2.
Someone else had the same problem and reported it on quality central as 106369 and same error message leading me to this mysterious DocWiki entry.
So data modules now have a framework affinity, and a designtime-only pseudo property, which according to the docs:
"Because the ClassGroup pseudo-property is used only by the IDE and is not a compiler-generated property (hence, 'pseudo-property'), ClassGroup is not documented in the compiler-generated Libraries Reference. The page you are reading is the documentation for ClassGroup."
So, the first time I even learn this exists is when it blocks me from copy and pasting components into my data module from an existing set of designtime building blocks that I didn't wish to rebuild from scratch.
Once I change the data module affinity, I can paste stuff into data modules without it bugging me. Thank goodness for Google-that-error or I'd be stuck.
If it is intended to help us write cross platform data modules, and yet it only affects the IDE, according to the documentation, that's inconsistent with the warning that you get when you play with this at designtime, here's the error you get if you change it:
EInvalidType : The following component(s) are not available in the specified
class group. This is likely to cause compile or runtime errors.
frxDBSet.TfrxDBDataset.
What I can't see is how that error message can be correct, and the documentation can also be correct.
The warnings seem to suggest compile, link, and runtime errors if this is set incorrectly. Curious minds who want to know what's really going on, want to know: What is this thing about and why did it get added to the data modules in XE2. I anticipate other people will stumble upon this weird feature, with the feeling that they've stepped in something like dinosaur droppings, and want to know what is up with this feature.
My best answer at this point is that a data module affinity for TPersistent which means, in XE2 lingo, that this data module doesn't want non-visual controls in it, that are VCL-specific. In a future version of Delphi, perhaps a similar marker would allow us to mark forms as being "clean of dependencies on the VCL or windows" too?
Update 1: The .PAS source code of your data module stores this pseudo-property in a way that looks a bit like a compiler directive, like this:
implementation
{%CLASSGROUP 'Vcl.Controls.TControl'}
I think it is pretty obviously what its intended use is for, and the documentation you link to is pretty extensive about that purpose.
It is meant to prevent VCL-only components from being placed on a FireMonkey-accessible DataModule, and vice versa.
Since TDataModule is initially framework-neutral, only framework-neutral components can be placed on it.
So obviously, your source DataModule has a different affinity than your new DataModule, which is why copy/paste does not work until you change the affinity of the new DataModule to match the affinity of the source DataModule.
I want to test a Delphi application with Coded UI Tests, but I have some problems. I want access to some elements in the UI but cannot access all elements.
There is a list on the screen with some rows (according to the search parameters) and I want to access these rows to check the consistency of the values. But with the cross of Coded UI Test Builder I cannot access the rows on the application. How do I access the rows?
I just found one solution for now: Develop an extension for Coded UI Tests to interact properly with my Delphi application like the sample on the Microsoft Web site. It's an extension for Excel that allow you to access each cell. But it sounds difficult and the application I have to test is really complex as well.
If your interface is plain VCL, you can access most components by using their underneath HWND handle. It will work for TEdit TMemo TComboBox TCheckBox and so one. But some graphics components won't be able to be accessible from GDI messages, e.g. TLabel or TGrid.
So I guess you'll have to use a Delphi plug-in in your application, to let accessible the VCL components level. Use the ComponentCount + Components[] properties of a TForm (via recursive call) to access your component to be tested. Then publish its properties to the Coded UI Tests extension, which is to be written.
I speak about a "plug-in" here, because I do not think we may easily have access to all classes to be monitored / modified. Some "plug-in" architecture may help an application to work as usual, or in "Coded UI Tests mode", during testing phase. Perhaps better that a separated compilation for the purpose of tests: you should better test the final compiled executable. If you want only unit testing, you may recompile, stub and mock your application to only test a given form. But you'll need to code the form to be easily unit-tested (using dependency injection or such), which is far from easy in the default Delphi world (as with other RAD approaches).
Could be interesting to initiate an Open Source project (included with DUnit?) to develop such a platform. Or use an existing UI test framework for Delphi as base. A lot of companies we work in are mixing .Net and Delphi technologies, and would benefit for such a tool.