XP error on CreateForm()

I have recently ventured into creating retail software, and have found a few things out in the process one of which I hope someone can shed some light on! I created a program using Delphi 7 build 4.435 not build 8.1, I currently have over 100 customers with my program installed onto their systems 75%-80% are all XP home and Pro while the rest are 98 and 98 se. out of the 75%-80% XP users I have had 2 come back to me and state that my program starts up encounters a fatal error then shuts down with little description of the error (exception 0x0eedfade) I was able to narrow it down to the Application.Initialize code, when it creates the "Main" form I get an exception. Since this is done in the Initialize code I am not able to receive ANY type of informative error. I removed the code that was in the Create section of the form same error occurs I did the same with show, paint and resize same issue. I also read awhile back that Delphi had some issues with createform() but I don't remember what the solution was / is or if this is my problem. What would be the next thing I need to focus on?

The hard part of this I am not able to visit the site and field test the system it is running on in order to get the full understanding of the problem. The weird thing is the 2 systems that are having the issue are the same type of computers with specs almost identical to my test bed computer give or take some applications. I have tried Eurkalog with no success since it will not trap exceptions in the Application.Initialize code, it just generates a fatal error. Any Ideas?

Thanks
Jeremy

most likely the problem is due to one of the components you are using on your form. Are you using Indy or any DB components?

Is you app starting any service threads?

Does you startup code require that certain files exist on the clients computer?

Does your main form use any COM/ActiveX components? ... in particular, are you embedding an IE (Internet Explorer) control?

Does your startup code require access to the system that may not be available to the user's security profile (ie: does your app require the user to have administrator access)?

Are you making use of Xp manifests? If not then there could be issues with you app being tied to (and requiring) a particular windows system dll version. Using XP manifests (embedded or not) can fix/help what has been previously known as "DLL Hell" through the use of side-by-side assemblies.



regards,

Michael

Thanks Michael,

Well looks like I am in it deep lol I am using Indy controls, ADO controls (to load a MS access Database) and the XP Manifest. I am not starting any threads now I was previously in an older version which is now gone. All of the files my app is looking for is either created at first run or if it is found to be missing / corrupt and the rest are installed onto the computer via the cd. If you would like I can give you a list of all the components and containers I am using. I can get this for you later today. I did send my customer a new debug version but I have not yet heard back, I was thinking it may be a code issues inside the one unit so I moved the creation order for the forms and left the issue form for last while i pop up a few message boxes before saying the other forms were created ok. This should prove both our ideas.



Ok since I am using the XP manifests in order to test and see if this is the cause I should just remove the instance of the object (A given)? Now for the Side-by-Side assemblies, I must say I have not heard of this but I am not to surprised. Would you mined going into a bit of detail or sending me to someplace that has more information on this?


Thanks a bunch!
Jeremy

I would suggest that you explicitly handle all component creation at runtime yourself instead of relying on them being instantiated through the default implicit dfm form constructor.

This way you can not only isolate and trap creation exceptions, but as an additional benefit, it will reduce the size of your compiled executable.



I'd be concerned about the Indy and DB related components and their properties. Does the DB connection autoconnect? Do any Indy components require or assume a live or existing net connection? What if the user has a dialup modem instead of a PCI ethernet card? Does your app make any assumptions about the user's system setup?



Why don't you log things to a file? You really should. If your application is not time critical, then all major events, and all object creation events could be logged to file. Having a log allows the end user to spot and fix most errors themselves... saving you time/money.


no. no need to do that.



In the past, programs compiled against the windows system libraries (CommCtrls, CommDlgs, Kernel32.dll, User32.dll...etc) required that the end user's system potentially have the same library versions as existed on the system used to compile the app... this of course caused many problems. This is not a problem limited to Windows platforms alone. The same problem exists on Linux, Solaris, Unix, etc...

Microsoft's solution was to provide Side-by-Side assemblies. It allows the programmer to include a manifest which details the library versions used by the main application at compile time.
Depending on what platform(s) your app is installed on (Win95/98/200/Xp/Longhorn/Vista...) the end-user systems may not have the required library versions installed.

The following link will explain how Side-By-Side assemblies can be used to aid in cross-Windows-platform compatibility for your app:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sbscs/setup/side_by_side_assemblies.asp



-Michael

Michael

Wonderful thank you for your help I will take all you have mentioned into major consideration, I did trap the errors on startup this time and I am going to add this to the final release for the end user. My customer received an error ( Error Creating Object, Please verify that the Microsoft Data Access Components 2.1 ( Or Later ) have been properly installed ). I had my customer download the Component Checker from MS site and the version installed is the MDAC 2.8 SP1 on Windows XP SP2. I know this version will work as I have the same version installed on my computer. I also redistribute the MDAC_TYP.exe to install with my program. The 3 DB components I use are TADOConnection, TADOQUERY and the TDataSource.

Provider is ( Microsoft.Jet.OLEDB.4.0 )

Connection String
( Provider=Microsoft.Jet.OLEDB.4.0;Data Source=' + FileName + ';Persist Security Info=False )

When the user starts up the program I have a routine that loads a specific database based upon the last use, this DB is ALWAYS on the clients computer so it is local. Since I am new to data access I am sure I have some setting that is not correct and causing the issue but I dont know where to start there.

I know I am asking a lot and I need to do my homework on this which I agree, I am only asking for ideas and help on what to look for next. I really appreciate EVERY bit of help you have givin to me, I am sure it will come back to you 10 fold!

- Jeremy

The issue has been solved, for the ones who would like to know it was a broken installation of the MDAC 2.81, all that is needed is to repair the installation.

How to Repair MDAC 2.81 under Windows XP with SP2

1. Open the folder C:\Windows\inf and locate the file mdac.inf.
Note: Your Windows folder could be named differently, e.g. C:\WinXP

2. Right-click the file mdac.inf and click Install.

3. When prompted for a location, point to :\Windows\servicepackfiles\i386

4. When prompted for the file handler.reg, either point to C:\Program files\Common files\System\msadc, or put the Windows XP CD in your CD-ROM drive. (you may receive file not found error(s), click cancel and the continue with the installation)

This reinstalls / repairs MDAC 2.81 under Windows XP SP2.