I'm trying to use DUnit, which came with RAD Studio XE2, to unit testing a Firemonkey app (C++).
The problem is, DUnit is a VCL project, and this makes me unable to include the Firemonkey Unit Forms (ex.: UfrmMain.h) on the testing project.
Even if I separate the Visual with Logic (MultiTier/MVC), i cannot include any Firemonkey library into my classes (sometimes this would be useful, when there is a class "CustomDatabase" which have a object of type TConnection, that is only available in Firemonkey - of course only an example).
The testing is possible when i separate the firemonkey code completely and leave it on forms, and the logic/data kept on classes with pure C++ code.
So, this "handicap" is actually a good thing? Forcing me to work with MultiTier/MVC? (This thing in C++ is new to me)
Or should i look for an alternative of unit testing, that lets me test forms too?
(Can you also recommend me some C++ project on github or code example which is separated in the mentioned way, where i can rely on?)
One possible approach would be to use TextTestRunner rather than GUITestRunner. I've never actually tried this but I think it quite plausible that TextTestRunner does not use any VCL units, or at the very least what it does use can easily be excised. And indeed a quick scan of the source code suggests that this will work.
Related
I have written a framework for Android and Windows, and got some tool that draw the forms and scripting that run on both enviroments. Just another solution like thousands.
What I want to do now is using Delphi (Xe2 in my case) to write an IDE like Delphi itself. That I could manage source files in a project and have forms. I have much of it already on DevExpress components. But I was wondering if there is anything that I could reuse to not invent the wheel again.
Certanly the drawing form should be necessary to have changes for my particular case, however it being capable of drawing forms with buttons, text, those common controls we find in majority of the platforms.
Right now I am using Balsamiq Mockup to draw and export xml to my compiler to integrate on the framework, it is nice, because it is a great drawing product, howeve there is a need to have all that IDE properties integrated and the need to put events on each control, for that an IDE all in one solution is better.
TMS Scripter -> I have found this commercial package, that comes with basically everything I need, scripting (I need VB but with different flavor, I believe it could be changed), form designer, project management, etc... It is very nice indeed. However I would like to hear of open source solutions
How about Lazarus? I think that's free, and it certainly has an extensive IDE.
http://www.lazarus.freepascal.org/
It's not a Delphi Open Source IDE, but I think it is free for use and feature rich:
MS Visual Studio Shell
what-is-the-visual-studio-shell-standalone-shell-good-for
RemObject use it for there tools. So it fits also for Delphi.
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.
I'm pretty new to Delphi and I'm trying to use the DEHL Collections library. (see http://code.google.com/p/delphi-coll/ ) I'm have a little trouble with it from the IDE perspective. It compiles and runs correctly, but Delphi XE shows errors anywhere I use the HashSet library. The biggest grievance is that is prevents me from using code completion.
The first location I get the error is in an object declaration:
uses
SysUtils, Windows, Collections.Base, Collections.Sets, Collections.Lists,
adscnnct, adstable,
uOtherClass;
type
OneClass = class(OtherClass)
private
_bad: THashSet<string>; // THashSet underlined
_good: TList<string>; // No problems
end;
The error states: "Type arguments do not match constraints"
I don't think it's configuration as I can use TList just fine, but here is how I set it up: I've copied the library to Projects/Libs/DeHLCollections/Library and compiled the library to Projects/Libs/bin. I've included the bin directory in my global library path, which got it to compile and run. I have tried adding everything (/libs, /DeHLCollections, /Library) to it as well in hopes of getting the IDE to help me out, but it doesn't seem to be helping.
Anyway to fix this, or do I just have to deal with it?
Using DeHL Collections version 1.1.1.119
Welcome to the troubles with using Generics laden code. DeHL and generics work a lot better in Delphi XE than in any previous Delphi version, but that's not the same as it "not having any problems". The problems I experience are exactly like yours.
My opinion is that DeHL shows every sign of having been written by a master delphi programmer, and that it's a thing of beauty, in some ways. It's also a source of great pain, through no fault of its own.
Delphi contains not one or two, but at least three (maybe four?) separate parsers, including the full compiler parser, and a few IDE-parsers used for things like Error Insight (the errors you see even before you build) and the code completion data parser. Each has different language support limitations with regards to generics. It is possible perhaps that DeHL could be written to avoid parser problems with all the various Delphi parsers. I have not seen a guide ever written that shows the limitations, but I wouldn't be surprised if complex type declarations in the form TSomething<TSomething<ISomethingElse>,TBar<IFoo>> breaks more than a few of those parsers.
If you intend to use Generics very heavily, you may as well turn off Code Completion and Error Insight. You might also want to save often, and be prepared to experience a lot of compiler problems. And don't try to compile generics-heavy code and put it in packages either. I have experienced a lot of URW and AV (internal compiler faults) when I write generics based code. I find that the Delphi compiler team is great at fixing whatever gets reported, but that the Generics are really most stable for me when I restrict myself to using the Generics.Collections that come with Delphi, and not using other generics based code. It seems it is possible to write stuff using the generics features, that the IDE and two-way tools, and code-completion is not yet fully ready to handle. That means, phenomenal cosmic Generic powers come at a cost to the classic RAD IDE productivity features.
That being said, the latest DeHL sources from Subversion work fine for me and build and run with no errors, but the most recent source ZIP of the entire DeHL collection had problems for me.
I expect that over the next few releases of Delphi, whatever issues have been found (and DeHL seems to be a great place to push the boundaries, and that's one of the reasons i'm a big fan of it) will be fixed, and you won't be wondering why heavy-generics break your IDE features, because they'll all be working again.
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.
I have seen that most of the components (VCLs) in Delphi are split in two parts.
1) DesignTime Package
2) RunTime Package
Why all this fuss. What difference does it make if both RunTime and DesignTime packages are united into one single Package?
I have never really been able to understand this separation logic.
So what is the logic behind this?
Once I had head someone mention that this distinction was made just to avoid adopting and following Component standards as laid down by Microsoft. Really there is no logic behind this.
Is this true?
A. Some components have large and complex design-time features such as property editors, which you may not want to include in your run-time application.
B. Some component vendors do not want to licence their large and complex design-time features for royalty-free run-time use, but restrict them to use by developers only.
If you had done a little bit of research, you'd have found this SO question asked less than 2 days ago...
As already explained the main reason is that you cannot include any Delphi Design unit in a runtime package. And there is no reason to bloat your executable with code that can only run within the IDE anyway.
Designtime stuff may use Delphi's
internal units/packages to which you
neither have source code nor are
legally allowed to distribute in
binary form.
You probably don't
want to make your application require Delphi
to be installed on the user's
computer.
The logic is to keep your own code separate from the "glue" code which makes it nice & easy to work with in the IDE.