0

I have a problem executing 64-bit version of my program:

_XMLDoc = new TBasicXML(_owner);
try {
  _XMLDoc->LoadFromFile(_filePath);
  }
catch (...)  {
  delete _XMLDoc;
  return "?";
  }

In 32-bit version, when _filePath does not exist, program goes into catch block, but in 64-bit version it does not. Actually, it throws EDOMParseError several times and it enters catch block after I press continue for each error dialog.

TBasicXML class constructor is:

__fastcall TBasicXML::TBasicXML(TComponent *Owner, UnicodeString encoding)
{
_doc =  new TXMLDocument(Owner);
_doc->Active = true;
_doc->Encoding = encoding;
_doc->Options = TXMLDocOptions()<<doNodeAutoIndent;
}

Is there something specifically I need to specify in project options for Win 64 target that defers from 32-bit target, to avoid such behavior?

Edit: I was focused on this part of code (parser), because it's executed at the program start. However, I've added this peace of code in my main form's constructor, before parser call: 

int x;
try  {
  x = StrToInt("not a number");
  }
catch (...)  {
  MessageDlg("Exception catched!", mtInformation, TMsgDlgButtons() << mbOK, 0);
  }

I've built 64-bit release version and started the program (Run without debugger). It simply aborts without any message. When the same program (release) is started with debugger (Run (F9)) it shows error message dialog (EConverterError) and then after continue is pressed it shows my MessageDlg.

Note: with 32-bit version, there is no problem at all.

Edit2: I've test some other projects, the same situation:

__fastcall TfrmMain::TfrmMain(TComponent* Owner)
    : TForm(Owner)
{
// test
int x;
try  {
  x = StrToInt("not a number");
  }
catch (...)  {
  MessageDlg("Exception catched!", mtInformation, TMsgDlgButtons() << mbOK, 0);
  }
//Ie settings
IEGlobalSettings()->AutoFragmentBitmap = false;
IEGlobalSettings()->MsgLanguage = msEnglish;
IEGlobalSettings()->EnableTheming = true;
// initialize spengine
speInit();  // delayed DLL load
FLeftId = 0;
FRightId = 0;
}

Again, 64-bit release version, when started from IDE, without debugger, silently terminates program, when started with debugger, works normally.

Edit3: Now, here is a mystery? From the example above, I've excluded DLL library (spEngine.a) from build and commented all code related to DLL entry calls and try-catch block works as usual. When spEngine.a is included, no matter if DLL loading (spEngine.dll) is delayed or not and without any call to DLL entries, try-catch block woks as previously described. Very strange. spEngine.dll calls custom Intel's ipp DLL build with MVSC2017. The similar try-catch behavior I have experienced with another library that calls OpenCV DLLs (wrapper built with MSVC2017). The complete source code is here: https://github.com/spetric/Lips

Note: 64-bit host application works well, no problems with functionality, only with strange try-catch block behavior.

S. Petrić
  • 80
  • 10
  • Why are you assigning an `Owner` to the `TXMLDocument` that is outside of `TBasicXML`? Consider changing `_doc` to `_di_IXMLDocument` and then use `(New|Load)XMLDocument()` to initialize it, instead of using `TXMLDocument` directly. Also, try catching the exception using `catch (const Exception&)` instead of `catch (...)` – Remy Lebeau May 11 '20 at 17:27
  • The first code block belongs to `TParseXMLConfig` class which is defined as `class TParseXMLConfig: public TParseXML`. Actually, TParseXML is a base class for all my "parsers". `TBasicXML` is a class that holds some base XML functionality (wrongly stated as a base class in my question, edited) . I admit...a little bit messy. I'll try to use XMLDocument interface and specify catch exception as you've suggested. – S. Petrić May 12 '20 at 08:05
  • When I removed libraries from project and added `#pragma comment(lib, "someLib")`, in main form, everything worked correctly on all Win platforms and all configurations. This solves the problem, but arises the question...why? – S. Petrić May 15 '20 at 08:26

0 Answers0