A good introduction to problem solving using Java is The Art and Science of Java[^]

codedgn wrote: The purpose why people post questions here is to seek solution not advice. You must either be particularly dense, or you know absolutely nothing about computing! As I stated before there is no solution to this problem, as is the case with many of the questions here. All we can do is advise the OP of that fact and make suggestions as to what other course of action they may take. The fact that the questioner does not like the answer makes no difference to the outcome.

Found it! Some external dll (G) I was using in B had an interface using CString. Since I am not allowed to use MFC, I redefined these to be string. I don't actually use these parts. Anyway, string is not the same as CString and this was causing an access violation, even though it compiled and linked, the rat. I solved this by taking a local copy of the G.h file of the external dll. In it I put includes so it could see CStrings. This actually makes the exclusion of MFC in my own code redundant, but I can't help that. The G people are not willing to work without MFC (neither was I actually). G also had some problems in its export functions, which are being repaired. We are pleased to find these bugs now and not after delivery. ------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

My advice is: rebuild all from scratch, saying bye bye to all the FORTRAN and Ada stuff. :) If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile. This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke [My articles]

Thank you. I do know where it crashes, it enters my little dll through an exported function, then instantiates the class in there, and dies in the constructor, right on the {. I can tell that its problem is a null or corrupted pointer, because the debugger lets me look at the assembly code, and it tries to jump to places it's not allowed to, an access violation, as it says. I am trying to get DevPartner to run again. (The newest version seems to be a bit buggy.) When it was running before, it complained about "Calling Virtual Functions from Constructors and Destructors" and stuff like that, which I have stopped doing (this is what I meant by improvements). Hence my question. Is it OK to put code - I mean, real code that does things - in the constructor and destructor, when the compiler allows it and DevPartner whinges about it? If I can't get it running this week I shall just have to deliver the debug version, which is not so tragic right now, but it bothers me. ------------- Ave computer! Hackitura te salutat! (I just made this up. Just to show you can hack Latin as well as C++.)

Ah, the helpful website cut out most of the messages because of strange characters. There are several ways to remove things from the list, and I have tried all of them, quite successfully, with all my included dlls and exes, with the exception of these std libs. Maybe there is a way to remove these results from the end result. It is very irritating, because my code is safety critical and I am supposed to be over 95% coverage, and this glitch pushes me down to 60% of code and 40% of methods. Here is just one of those messages: std:: (underline) DebugHeapAllocator (pointed bracket open) char (pointed bracket close) deallocate::deallocate(unsigned int) ------------- Bibo ergo sum modified on Thursday, March 26, 2009 3:26 AM

That was it! I had to change the C run-time library from debug multithreaded DLL to debug multithreaded. ------------- Bibo ergo sum

Yes, I spotted the key, I need some of those too. Thank you for the tutorials, I shall have a look. ------------- Bibo ergo sum

Thankyou for your quick reply. I realise I had hit on one of the few const char definitions which only has one character. Those with more than one worked fine the way it was. ------------- Bibo ergo sum

Fixed it! I finally ported the old Fortran to Windows and recompiled it. I put some prints in to see what it gets up to. It works. The problem was the Fortran having been compiled under Cygwin, some kind of Linux for Windows. It ran under Windows, but not quite. So when I compiled it myself, it could use the strings to open the file. Just because it runs from the command line does not mean you can embed it and it still runs.

That was very kind of all of you - I now know that you really can debug in release mode - but the problem was something else entirely. When I first made my exe it was a dll project, then I decided to make an exe after all, and since I was in a hurry I did this by copying and renaming, then changing the properties to fit. Anyway, I ended up with both main and InitInstance. Debug runs main, it seems, and release takes InitInstance if it can find one, or maybe main is optimised out. I commented InitInstance out and suddenly all is well. ------------- Bibo ergo sum