I have a project group containing two projects that share one source folder,but do different things.What I find strange is the use of 'project group',but I don't want to turn this a subjective question,thereby I directly ask you:
How do I run all the projects in a project group - is there a short way?
Thank you in advance!
Actually, all of you are wrong. You can debug multiple programs at the same time.
I don't know when this was first implemented, most probably when the project groups were added to the Delphi, but I'm using this since "forewer" and I'm sure that at least Delphi 2005 was capable of doing it.
In short:
Create a project group with two programs.
Build them all! You won't be able to use the compiler after you start the debugger.
Activate the first program (double-click on its name in the Program Manager) and press F9 (run).
Activate the second program in the Program Manager (you cannot use the drop-down next to the "Run" toolbar button for that as it will become disabled in the previous step) and press F9.
Voila! You have two programs running under the debugger. You can set breakpoints in any of them and they will work just file.
This approach works with any number of programs. (There may be some hardcoded limitations but I've never run into them.)
The debugger can debug only one application (actually: Process) at the time, and if you run from the IDE it is in the debugger.
So I think the answer is : you can't.
Well, I guess unless you count dlls that are launched in the same process, but are individual projects. (seeing the other post), but I never tried that.
To run all the projects at once, add a new batch file to your project group. Make the batch file run each program, and when you want to run them all later, simply choose the batch file in the project group and run it. This isn't the same as debugging all the projects, just running them. It's simply a way to automate the procedure given in Bruce's answer.
You can only debug one project at a time, but you can run as many as you like from the IDE without debugging.
Shift + Ctrl+ F9
Update: I stand corrected. You can debug multiple projects at the same time. Excellent for debugging a client and a server at the same time.
The projectgroup is a tool to build multiple projects.
You can select build all from here to build them all.
You can run several from within the debugger if one is a program and the others are dlls that are used by the program.
Multiple programs's can't be run/debugged at the same time.
Although you can use a program as a DLL but I'm not sure if the IDE can handle that use. In that case you can use a main procedure which is the only thing called from the main program. Then you should export this main proc. Create an additional exe project that calls all of them from different threads. I have not tested this. And it is a hack, but it could probably work.
But why do you want to run/debug several apps at the same time?
As a side note: Check all dependent projects (right click on project -> Dependencies) to have them build automatically before debugging.
Related
I am trying to use an application called CLUT.exe which is an old application for MS-DOS that can be used to reindex NTX files for DBF databases.
(This is not the main topic, but I am just writing this if someone wants to test the app and don't trust at all about the content).
The problem starts when trying to run the command line version through console (cmd.exe) and this error appears:
C:\>CLUT.exe [arg1] [arg2] [arg3]
run-time error R6009
- not enough space for environment
So, according to what I've searched, this could be a possible solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;230205
but it doesn't work and every alternative that I found to solve this over the internet is the same.
Another alternative could be to make right-click in the .exe file, go to Properties then Memory tab and increase the Initial environment memory from Auto to the max value but it doesn't work too.
Well, I am stuck and no "possible" solution is working for me. If someone is interested, knows more about this issue and want to test, you can download the application from here (click "Free Download" green button):
http://www.filebasket.com/free/Development-Clipper-programming-language/clut-exe/13996.html
or directly from my DropBox:
https://dl.dropbox.com/u/15208254/stackoverflow/clut_214.rar
Just to know, I am using Windows 7 and the CLUT.exe application is a Clipper based app (old programming language) that may run under windows console (cmd.exe).
Wikipedia does mention other dos emulators but, oddly, doesn't mention BOCHS.
Reindexing NTX files is not a difficult thing to do, and can be done with tools other than CLUT. For example, many of the utilities listed on this part of Download32 could be used. Otherwise, you could write your own using Harbour Project or xHarbour. Or contact me off list and I'll cook up something in Clipper 5.3.
LATER
If I read the README correctly for CLUT, it's a replacement for the DBU utility that comes with Clipper 5.x. I can supply you with a build of that if you're unsuccessful with other approaches.
I found interesting problem with Win7/X64 machine.
For this time I haven't got problem with Delphi 6 and UAC.
The exes are working in their's place, so I can use Delphi debugger with them.
But today I got error on run the project: "Unable to create process. For this operation you need higher user level".
How can I prevent this side-effect?
What causes this?
I don't understand why the older projects are running fine, but this new isn't...
Thanks for every idea, link, information!
Additional info:
Normally I using the Delphi 6 IDE with normal starting (without SysAdmin rigths).
So it is never asking me with "really?" kind UAC questions.
And every of the older projects are usable with Delphi 6 - I can build, run, debug everything.
This problem happened with only this project, so I try to find the differences if possible to solve the problem.
I using normal directory ("c:\dev\anyproject"), others are using "c:\dev\otherproject1..2..n").
Does your application request elevation when started from Windows Explorer?
Does it have a manifest?
The name of the exe, like setup.exe, could also trigger elevation. See an outline of the Installer detection technology.
Non-elevated process can't debug elevated process.
If your application requires elevation at the start, then you would need to run the IDE elevated to be able to debug it.
Starting your IDE as an administrator should solve the problem (option in the context menu).
If not, you could always disable UAC while developing.
There is a number of limitations that needs administrator's rights.
For example: you cannot write data directly into program files directory.
We currently use Delphi 2009 and GIT to develop an application. We have set up a prebuild script to generate a version number and build ID using information from git and compile this as a resource that is included in the project. The problem is that this script doesn't run on a regular compile. This means that the other developers can end up with a discrepancy between the actual version number and the number in the resource (especially when switching branches in git).
Since we use our software to make some critical calculations, we would like to use this build id to reproduce calculations and track down problems.
Other than trying to force my developers to frequently press shift-F9, how can I ensure that the the prebuild script gets run when necessary (ideally at each compile)?
Jason
UPDATE: It's true that the pre-build script gets run at each compile. The problem was that I expected to get a different result pressing F9 after making a tag in git, even though no code had changed.
We solved a similar issue by writing a custom IDE plugin which uses the IOTAIDENotifier50 interface. Specifically using the BeforeCompile method, to test some required project settings and also generate dynamic version information (VERSIONINFO resource). It gets called for every type of build (compile and build). We also generate a unique exe serial number and log everything, which helps us track down issues and is similar to your script. For completeness we have only done this in Delphi 2007 and Delphi XE.
Pre build actions do run before every compile.
You state in a comment that the actions sometimes don't run when you press F9. That makes sense because F9, or Run, only invokes a compile if source is deemed to have changed.
A BeforeCompile notifier plug in will behave in exactly the same way. Your solution is to make sure that you compile before running using Ctrl+F9.
Our application requires quite a few tools and utilities we have written to support our product. Things like data converters, backup utilities etc. Currently, each of these utilities is a separate Delphi Project. On top of that, many of these projects also have a corresponding DUnit project for unit testing, which also have to be a separate project. We currently have 13 separate Delphi projects. These projects are all in one Project Group.
Is this necessary? Do we have to have so many separate projects, or is there a way in Delphi to have multiple entry points into the same project?
Also, sometimes it would be convenient during development to just write some code and 'run' it. To do this now I end up hacking the project file; commenting out the normal behaviour and replacing it with the code I want to run. Is this the only way?
We use Delphi 2010 if that makes a difference.
You can do either of these pretty easily:
Combine your projects into a project group, to be able to work with them together more easily.
(My preference) Separate your projects into different units (instead of project files), create a single application that uses all those units, and call different functionality based on command-line parameters (see ParamCount and ParamStr in the documentation) You can then easily write unit tests by testing each of the units (pun not intended) separately.
Regarding your edit: Delphi is a compiled, not interpreted, language. You can't just "run" code without compiling it, unless you can use functionality that's in your app using the Evaluate/Modify menu item during debugging. (Set a breakpoint and run your app. When it hits the breakpoint, use Ctrl+F7 to open the Evaluate/Modify dialog. Note that this has limited functionality due to the nature of the optimizer and compiler.
Organize your project in one or more Project Groups, and you could use project (exe) parameters to execute just some part of your exe.
As it was already mentioned you can convert mini projects into units. Then use compile conditionals ($ifdef etc.) to select which unit is being included in the compiled program. It would be also handy to be able to automatically switch the name of the generated executable file. I think it would be possible to create a relatively simple OTA (Open Tools API) plugin that could control all those features.
To run small parts of code you can create a separate lightweight console project where you can paste the code to the main function.
My problem is to create an ant target for automating our installer running in console mode.
The installer is created using InstallAnywhere 2008, which UniversalExtractor recognizes as a 7-zip archive. Once I have the archive unpacked, it appears that the task can use an input file to drive the console (at the very least, it appears that emitting a quit shuts everything down correctly, and output is captured).
So it looks to me as though I have all of the pieces I need for proving out this idea except a clean way to perform-self-extraction-then-stop. Searching for a command-line argument to stop the auto execution has not produced a likely candidate, and the only suitable ant task I've found ( http://www.pharmasoft.be/7z/ ) isn't so clearly documented that I have a lot of confidence in it.
The completed completed is expected to work in Windows, Linux, and a small handful of other Unix environments.
What's the best practice to use here?
Since you control the installer creation, can you run the self-extraction step on your machine, package the results before the installer is launched in a ZIP file, etc. and use that instead of the single file executable? Not very elegant but it may work.
Also, I am a bit hesitant to blatantly promote my project :) but since it has been a while since you asked the question and nobody has answered, have you considered an alternative? Our project InstallBuilder allows you to install in unattended mode directly, without having to autoextract the contents. Just invoke the executable with --mode unattended, pass any additional options you may need from the command line or an external file and you are good to go. We have a lot of ex-InstallAnywhere customers :)