May I ask for some guidance please ?
Development machine – Windows 7 64bit
IDE – Delphi 7 pro (with 7.1 update)
Target machine for install – Windows XP (SP3) – NB this is the Win 7 Virtual Machine
I have built a small application, nothing more than a test app. A grid, a TADOConnection connected to an MS accdb file and a few TADOTables. Using Inno Setup I have also built an installer. I promise, it’s a very simple app.
When I install the ‘application’ on the XP virtual machine, everything goes according to plan, ie no error message and the installer completes. However, the application will not start. On the same XP VM, I have D7 installed and, here’s where it get’s weird, if the IDE is running, my application will launch without issue. If I close the IDE, it, my application, will fail to start again.
All I get is an hourglass for a second or two, and that’s it … no error message, no horrible MS dialog asking me if I want to send them info about this dreadful application, in fact I get no feedback whatsoever.
NB - Whether run from the IDE, or outside of the IDE, on the Win 7 machine, the application runs just fine.
I’m obviously missing something quite obvious, but I’m lost. I have even tried ….
program Project1;
uses
Dialogs,
Forms,
Unit1 in 'Unit1.pas' {Form1};
{$R *.res}
begin
Application.Initialize;
ShowMessage('Starting');
Application.CreateForm(TForm1, Form1);
Application.Run;
end.
But I do not get to see the ShowMessage dialog.
I have read the many ‘Hello World’ tutorials. Gleaned a great deal of knowledge from generous SO contributers (thank you). But there must be another tutorial that teaches me what to do in order to ‘prepare’ my application for inclusion in an installer. I thought that if I unchecked the ‘Build with runtime packages’ in Project Options and then did Project > Project Build, I could build a file with everything I needed to run the application outside of the IDE.
May I ask if anyone could point me to the last piece of the jigsaw, please ?
Incidentally, is there a way to debug an executable outside of the IDE ? Perhaps some switch within Delphi that would produce a log file when the application starts … or tries to.
Thanks for your time ?
Regards,
John.
EDIT - I mentioned earlier that the file will run outside of the IDE on my W7 machine. I got this wrong ... it won't run unless D7 is up and running too. Also, I made a copy of the original folder with this file in and started messing with the Project Options switches. Suddenly, the new file is twice the size and runs OK. Problem ... I can't replicate whatever I changed on the original file / Project to know for certain what I have done is the cause / fix.
Edit 2 - OK - the issue definately has something to do with the different file sizes. I have created a folder on the XP volume and dropped a copy of all of my BPLs from the Output directory in Win 7 Delphi install. Dropped my exe (the file that will NOT run outside of the IDE) in there, and also my accdb file too. Double click and ... Hey Presto - it runs. the grid displays my sample data ... beautiful.
Here's the thing ... Project > Options > Packages > Build with Runtime Packages is UNchecked. This should build me a LARGE exe file - (is that correct) but it builds a relatively small exe that needs the BPL's !!!!
Will do some more testing ...
You probably have your tconnection as connected in the ide.
That lets you see how things will look with real data within the IDE, but now when you run your application, it tries to connect right at the start, when maybe not everything is set up correctly yet.
One possible solution: leave the connection component disconnected, and connect at a later stage, for example via a "connect" button.
At least it will be easier to properly handle exceptions like that.
Related
It is probably me being stupid, but I am having problems detecting if a network drive is up, but only when running the program in the IDE – when running the program outside of the IDE, the network drive is correctly detected. The IDE works fine on Windows 7.
While the program in question is different, I can reproduce the issue by creating a new project and adding the following into the Forms OnActivate event:
var
bRet: Boolean;
LTemp2: string;
LFreeSpace: Int64;
LTotalSpace: Int64;
begin
LTemp2 := 'T:\';
bRet := GetDiskFreeSpaceEx(PAnsiChar(LTemp2), #LFreeSpace, #LTotalSpace, nil);
ShowMessage('GetDiskFreeSpaceEx: Drive T: is up? '+BoolToStr(bRet, True));
end;
Assuming I have a networked drive T:, if I run the program in the IDE then the above always returns False, but if I run the built program from a desktop shortcut then it returns True. I get the same behaviour if I run it via a button click after the program starts. Doing DiskSize() and FindFirst() on the root directory give the same results.
It is a clean Windows 10 install, not an upgrade, with a clean install of CodeGear 2007 with all the patches applied. I have tried “Run as administrator” and all the Compatibility Modes back to Windows 7.
Am I doing something stupid?
After R. Hoek's great insight, and while it does not fully sort out the issue, it is at least enough for a workaround. By the way, at least in my case, it does not matter if I launch Delphi 2007 with "Run as administrator" or not.
I added a TOpenDialog hooked up to a button: once I run this and select a file on T: then GetLogicalDrives() works fine.
So what I now suspect is that I installed Delphi 2007 as an administrator - not sure how, but I think I will re-install everything.
Even if that does not resolve it, and since it only occurs in the IDE and not in production usage, I can add code to pop up a TOpenDialog if GetLogicalDrives() returns 4.
Weird. Thank you all very much.
By the way, one aspect of this discussion may not have been clear: Delphi 2007 was running under the user account (and it could see the network drive without problems) - it is only the program which is being debugged that cannot see the networked drive. That is why using the TOpenDialog resolved the issue (until Delphi or the computer was restarted).
I am using Delphi 7.
TOpenDialog.Execute hangs the program if launched from the standalone
EXE.
When the project is executed from Delphi 7 it does not hang.
It does not matter what I add, even a blank project with a button
that has OpenDialog1.Execute on it will cause the hang when clicked.
This problem is recent. Projects compiled before a while ago do not have the hang.
I used the same Windows installation (Windows 7 Ultimate 64bit) and
the same Delphi 7 for years now.
Projects compiled before a while ago do not have the hang.
Projects from Delphi 7 that are complied in Delphi 10 will also cause the hang.
It does not happen in CLX applications, whether in debug or standalone.
Here's an example of what seems to be causing the hang:
procedure TForm1.Button1Click(Sender: TObject);
begin
OpenDialog1.Execute;
end;
Update:
Cause might be "InitialDir" being the Desktop. If it's set to c:\ for example, it won't happen.
Another thing to look at is Project -> Options -> Compiler Messages (are there any unchecked?) If so, those are exceptions begin ignored by the IDE's built-in debugger. Check them, and run, then you might see what is causing the hang-up.
The only time I have been able to produce this is when I have a network share that is sluggish or not there... during the IDE debugger it timesout and keeps going, however, standalone it will eventually timeout, but, much longer.
(Most likely it is something in your Project -> Options screen). As I do strange things that most people never do :-) (sshfs for example will cause this).
I once had this problem in some of my application if i wanted to access network shares. By including the compiler switch
{$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE}
I could get rid of the problem. See also this blogpost. But be aware, that this switch has some restrictions.
As Microsoft mentions, "The /TSAWARE option is enabled by default for Windows 2000 and later, for Windows and console applications", meaning every .NET application has this switch turned on by default.
Here is the problem I've met:
Working in BDS 2006 IDE, my older computer gone, new ( i7 mount ) has been built and it has Windows 7 Ult OS 64bit, where 2006 was installed and QuickReports Pro as well as eDocEngine, FIB+, TMS, LMD, ZEOS & DB Comparer Component Packs - I use them in my products.
On computer I have Office 2010 installed as well, by default in 32bit version and Adobe CS6. That's it.
After installation I tried few times reinstall RAD 2009 and anyway, always the same problem, to simplify it is 100% reproducable like that:
Create new Delphi VCL Forms application ;
Click File / New / Other and goto, say, "Delphi files" and select Frame or DataModule. When new file is created, all the time we have message:
"Stack overflow - save your work and restart Delphi for Microsoft Windows"
After that IDE set in bad state and next F12 ( show VCL designer) closes Delphi with General Error.
Any idea what happens?
As I said, I tried few time uninstall - install 2006, start in any personality, use / do not use any of the updates or IDE fixes from Andy's site, nothing helps.
Any help would be greatly appreciated.
You can try running a second instance of the IDE in the debugger.
Create an empty dll or package project.
Open Run > Parameters
Set the host application to $(BDS)\bin\BDS.exe
Then just hit F9 to run the second instance of the IDE in the debugger. After that just follow the steps to reproduce the problem and wait for the exception. If all goes well you'll get a complete call stack to step through.
Note: You may see various other exceptions occurring as the IDE loads. These are normal and can usually be ignored.
Also you didn't mention what version of Windows was on your old machine. If it was Windows XP Uwe could be right. XP was a little more lax on security by default than Vista or 7. The new default is to restrict write access to any folder under Program Files. If that turns out to be the problem you can adjust the write permissions for $(BDS) for whatever user account you use for development.
Delete de PackageCache in Embarcadero registry entries. Its not a complete solution but worked for me.
Got that from here: http://qc.embarcadero.com/wc/qcmain.aspx?d=118669 (last answer).
I have no BDS 2006 at hand, but is it possible that the default folder for new projects is located below the Program Files folder? In that case there might be no write access to that folder.
I recently posted this question about my inability to get Delphi 2010 working with remote debugging. I have not had any success and decided to post up a simple step-by-step test technique that might highlight what I'm doing wrong. THIS IS REALLY IMPORTANT to me - I've used Delphi since V1.0 and earn my living from it. Being stuck like this is a pain and its keeping me on Delphi 7.
Anyway, here goes.
Ensure that Delphi 2010 has updates 4&5.
Fire up Delphi 2010, then File | New | VCL Forms App. Put a button on the form, put 'ShowMessage( 'hello' ) in the button OnClick event. Save the project and its unit in a local folder "C:\scratch". Build the project, run it, click the button, 'hello' appears, all fine.
On a networked PC (194.168.1.64), create a new folder "c:\DebugTest" and share it with R/W access.
On 194.168.1.64 install the Remote Debugger from the latest download on the Embarcadero Website (RemoteDebugger_upd2.exe). CLick rmtdbg140.exe to run. Accept the 'un-block' message from the firewall.
Edit the DEBUG build configuration compiler settings with Output directory=\192.168.1.64\DebugTest and unit output directory = c:\scratch - see
Edit the Linking settings to set Debug Information=True, Include remote debug symbols=True. See
Leave compiling settings at defaults. See
Do a full build. The relevant project exe 'project2.exe' and 'project2.rsm' appear in the remote folder \192.168.1.64\DebugTest. Blue dots are visible in Unit2 in the IDE.
Set a breakpoint on the 'ShowMessage' line (the button OnClick event).
Use 'Run' | 'Load Process' with Remote path=c:\DebugTest\Project2.exe, Remote Host=192.168.1.64 and Working directory=c:\DebugTest see
Click 'Load'. The visible breakpoint is immediately disabled, the project starts running and opens the CPU window and stops. Pressing f9 cause the exe to run fully on the remote machine, the button works, you just cannot debug it.
I've tried various 'obvious' things like firewall off but all to no avail. Could some kind person suggest further ideas?
Many thanks.
Well, for me the problem has now been solved, although as a 'work around' and after significant interaction with Embarcadero and an upgrade to XE (which also did not work).
It would appear that the remote debugger is flaky (or possibly just picky) in its ability to load rsm (remote symbols) files - they are still looking into why mine wont load. My rsm file is big at around 50Mb although this is no problem for Delphi 7's remote debugger.
The work around involved upgrading to Delphi XE and then choosing the compiler link option 'Place Debug Information in separate TDS file'. This seems to create a tds file onthe remote target instead of a rsm file and breakpoints then work fine.
I've submitted my rsm and tds files to Embarcadero for investigation as to why this happens.
What Windows OS? Maybe run rmtdbg140.exe as admin.
I run D2010 remote debugging on XP versus XP. My How-To is at http://blog.runbits.com/post/Remote-debugging-Delphi.aspx
I had this problem. Installing Update 4 for Delphi 2010 solved my problem. It is also listed in the list of fixed problems of Update 4.
It is imperative to have correct time zone and clock on remote system. In my case I set up remote debugging and when I load process the breakpoints turned green. I checked remote system timezone and clock, set it right and remote dubugger worked again.
This is occurring on 2 machines that are both running Windows XP Pro SP3, yet it runs OK on my development machine within in or outside the Delphi IDE.
Running Windows XP Pro. Exe compiled under Delphi 2010.
When I run the exe I get the Windows Reporting error "Neopos.exe has encountered a problem and needs to close. We are sorry for the inconvenience"
I know it is happening somewhere in the form create of the main form.
Application.Initialize; //Runs this
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
It does not get to: procedure TfmMain.FormCreate(Sender: TObject); in the Main Form and I don't know how to track down this error and debug it.
What happens between: Application.CreateForm(TfmUDF, fmUDF); AND procedure TfmMain.FormCreate(Sender: TObject) in my main form.
How can I trace this to find out what the hell is causing the Windows Error.
Of course the Windows Error report contains a long listing of information. Where can I look in that to find the cause or at least a clue on the cause of the error.
This error has now stopped all development work (and ruined my weekend) so I urgently need to fix this.
The most straightforward route to take would be to include a product like MadExcept or JCL Debugger into your application, to get a full call stack (including line number) of the point of failure. We've rolled our own years ago, and it has been a tremendous help in situations like this.
One alternative, but lots more cumbersome, would be to generate a MAP file from your project, use MAP2DBG to generate a .MAP file, and use the Windows Debbuging Tools to get about the same information. This approach is a lot more hardcore, and only advisable if you really want to learn a lot about the internals of windows debugging (and enjoy working with arcane tools).
Another alternative would be to attach to the failing application from your development environment using Remote Debugging. Only applicable if you have a fair amount of control over the failing machines.
#user576639, here are some debugging ideas:
Look into the System's Event Viewer
If you got the exe has encountered a problem and needs to close chances are you'll find something about it in the System's Event Viewer. That should be your first step.
Any special DLL's required?
Do you need MIDAS.DLL?
Are you using an database engine? Does it require some sort of client library?
I'm talking from experience here: My development machine obviously has all the libraries I might need. Most of my clients also have most of those libraries because they have my software installed. At times I put out small helping applications that don't go throw extensive testing and they fail to work on SOME machines but work fine on other machines. Why? I used TClientDataset and forgot to include MIDAS.DLL with the application; Or the application is trying to access a Firebird SQL server but the user doesn't have Firebird client library installed.
Printer driver issues
Boy I hate Delphi's printer handling. Also hate buggy printer drivers, haven't made up my mind about what's worst. If you have something on your main form that might be requesting information about the default Windows printer (example: an REPORT) give this a try: Install an sane/simple printer and set it as the default printer. If the user has Office 2007+ installed, set the "Microsoft XPS Document Writer" the default printer.
I have seen bad printer driver + delphi issues manifest themselves with the "exe needs to close" symptom.
Prepare an special build of your application
If you got this far without fixing your issue it's time to create an special build of your application that's capable of providing more information. First of all I'd try adding this to your DPR file; Don't know if this is still useful for Delphi 2010 but it did help me see some early exceptions with a Delphi 7 application:
function HandleUnhandledException:integer;stdcall;
begin
Result := 1; // 1 = EXCEPTION_EXECUTE_HANDLER
end;
// and then immediately after "begin" in your DPR file:
begin
SetUnhandledExceptionFilter(#HandleUnhandledException);
// ... the usual stuff goes here
end;
Add some ShowMessage-s to your Main Form's code, in your OnCreate handler (if you have one), in your Create constructor (again, if you have one). If you're adding an ShowMessage to your Create destructor, make sure it's after the "inherited" call. This will help pin-point how far the loading of the form goes before it fails.
If all else fails...
Create a new, blank form; Make it the new Main Form (so it's initialized before your former Main Form). Test it on the client's machine - does it show up? It most likely will, if it doesn't you've got some serious problems.
Start copying the components from the former main form to the new main form; Only the components need to be copied, not the code: Your error is probably caused by some component failing to initialize properly. Make sure no component has "Active=True"! Copy the components in small batches, test often. If you spot the component that causes your form not to load on the client's computer, tell us about it and we'll try to help.
If you manage to get all your components on the new form, write an OnCreate handler that sets Active := True for all the components that need that. Did that fix the issue?
If you got this far then all the components you used on your main form can load properly. The problem's related to YOUR CODE. Start copying all the code from your old main form to your new main form, in small bits, and test. You're bound to find the peace of code that causes your application to stop loading.
Use dependency walker to see if you're missing a required DLL.
You can use information from system reporting (your error and suggestion to send it ) with Error Report Grabber ( http://www.maxerist.net/main/soft-for-win/err-rep-grabber ). I developed this tool when I desperately needed to track a error that appeared very rarely so almost non-reproducible. It helped me to track the information from stack to find actual place in the code.
The tool works only on XP (MS removed this dialog in Win7 and probably Vista), but I see that your cases are XP so this can help.
UPDATE: if you're not familiar with assembler and everything, this can work like this.
You should compile you program and don't change anything. Save the report on a bad machine, copy the file to your developer machine and open to view the contents. Look at the stack of your main thread in the report and find numbers more than $00400000, they're usually the addresses inside the procedures that called some other procedure and wait for return. In your developer machine, start the program and stop at any line, open CPU Window and on the main list with assembler instruction right-click and choose go to address, enter this address. You will see other assembler lines, but wrapped with pascal constructions you can probably recognize as yours
Thanks a lot for the help.
In the end I reverted to a recent backup and traced it down to a particular form.
I did not actually find the error, which is a bit worrying, but in any case I am back up and running (phew!!)
I made the error to occur on my development machine also, when, and only when, I use my install program (Inno Setup) to compile a setup.exe and which installs the exe as well as installing postgreSQL. Seems really strange, as though there is a problem with the setup compiler. In any case I have not seen the error again. I guess it will remains a mystery, like women.
In Delphi withing debugging options select debug dcu's, this will allow you to debug into the Delphi source code for TForm and its descendants and you may be able to track down a more likely culprit.
Set a breakpoint on
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
and then step into the code to see where the issue is.