Problem with VC++ and CDR X4

[Tomasz]

Hi all,
encouraged by Alex, Jemmyell and others who made C++ dlls for CorelDRAW with great success, I started learning C++. I have VC++ 2008 Express installed on two WinXP SP3 PCs. Before experimenting with dlls I attempted to write very simple console exe snippet in order to check if it will talk to Corel at all:

#include "stdafx.h"
#import "vgcoreauto.tlb" rename ("GetCommandLine", "vgGetCommandLine"), rename ("CopyFile", "vgCopyFile"), rename ("FindWindow", "vgFindWindow") no_namespace named_guids
#import "CorelDraw.tlb" rename ("FindWindow", "cdrFindWindow") named_guids

int _tmain(int argc, _TCHAR* argv[])
{
	CoInitialize(NULL);
	CorelDRAW::IDrawApplicationPtr pApp(L"CorelDRAW.Application.14");
	CorelDRAW::IDrawPagePtr pTargetPage = pApp->ActivePage;
	pTargetPage->ActiveLayer->CreateRectangle(1,1,2,2,0,0,0,0);
	try
	{
		pTargetPage->CreateLayer("testlayer");
	}
	catch (_com_error)
	{
	}
	CoUninitialize();
	return 0;
}

I was very surprised to see that though the program works perfectly on my work computer with CorelDRAW 12 installed, it generates errors while being launched on home PC with CorelDRAW X4. The error message box during debugging says:

Unhandled exception at 0x774fcdbd in wpsCorelTest_03_cppConsole.exe: 0xC0000005: Access violation reading location 0x00168678.

Debug pane pinpoints the problem at m_pInterface->Release() in comip.h header:

    void _Release() throw()
    {
        if (m_pInterface != NULL) {
            m_pInterface->Release();
        }
    }

There were neither errors nor warnings reported during building and linking processes. Also surprisingly despite errors the program does what it is supposed to do - draws a rectangle and adds a layer. Can you enlighten me how to reference CorelDRAW X4 properly in C++?

Tomasz

[jemmyell]

Hi, I support V12, X3 and X4 in both the DXFTool and DragonCNC. BUT I must recompile the DLL that uses CorelDRAW for each environment. Also, I have never been able to run my DLLs under the debugger, CorelDRAW crashes every time.

Put all the calls to CorelDRAW in the 'try' block, you may be surprised that something else is not working.

Take the DbgMsg library and header that I have posted and use it for debugging.

Why UNICODE? I only use UNICODE where I need to localize a UI.

These are all differences to how I work.

-James

[Alex]

I agree with James. Just wrap everything in try-catch block:

int _tmain(int argc, _TCHAR* argv[])
{
  CoInitialize(NULL);
  try
  {
	CorelDRAW::IDrawApplicationPtr pApp(L"CorelDRAW.Application.14");
	CorelDRAW::IDrawPagePtr pTargetPage = pApp->ActivePage;
	pTargetPage->ActiveLayer->CreateRectangle(1,1,2,2,0,0,0,0);
	pTargetPage->CreateLayer(L"testlayer");
  }
  catch (_com_error& e)
  {
     _tsprintf(_T("Error occurred: %s\n"), e.ErrorMessage());
  }
  CoUninitialize();
  return 0;
}

Something along these lines (haven't tried that code myself, so there might be some typos).

Why UNICODE? I only use UNICODE where I need to localize a UI.

I don't understand why NOT Unicode? We are way past the old ANSI era... File names could contain various characters, etc. If you are not using Unicode you won't be able to open those files, insert text in different languages into CorelDRAW and so on...

So, I would say, if you are not creating your applications in Unicode, you are stuck in the past

[jemmyell]

Alex,

I do agree about UNICODE, my latest app I just released has localizations for Traditional and Simplified Chinese and Arabic so far. But I have never used it for SDK calls, so I was just pointing out the differences from how I am currently working.

I don't think any of the other example code that has been posted here has used UNICODE.

-James

[Tomasz]

Alex, James,

amazingly putting everything into 'try/catch' wrapping resolved all problems. No errors are generated now. Thank you for the tip!

James, I remembered to use cdr12's typelibs with cdr12 and cdr14's typelibs with x4 so the problem wasn't here. Curiously I had to rename "FindWindow" during import of both vgcoreauto.tlb and CorelDraw.tlb in both cases.

As regards unicode, I work in Polish environment and always switch to extended charsets whenever I can. However this time Visual C++ was faster then me and having detected Polish WinXP added _TCHAR on its own.

Tomasz

[jemmyell]

Tomasz,

Good news. It seems you are having fun, that is the secret to satisfaction in this craft!

If you develop DLLs using the V12 object model you can run on V12, X3 abd X4 with only a recompile. Rename the typelibs so they can all reside together.

I have a header file "CorelDRAW.h" that #imports the three different environments according to a single setting. Then I have some batch files that scan for an embedded string and then rename the resulting DLL as "MyDll_X4.dll", "MyDll_X3.dll". etc. My plugins connect to these DLLs with a LoadLibrary / GetProcAddress using the correct DLL name per the plugin compilation.

I only use plugins to put buttons on the toolbar. That way I can still call the DLL startup from VBA in V12.

-James

[Alex]

Originally Posted by jemmyell

Alex,

I do agree about UNICODE, my latest app I just released has localizations for Traditional and Simplified Chinese and Arabic so far. But I have never used it for SDK calls, so I was just pointing out the differences from how I am currently working.

I don't think any of the other example code that has been posted here has used UNICODE.

-James

<rant begin>
100% of my applications are Unicode. It's absolutely essential with this global economy to be able to read files in different languages. Even imagine you copy a string in Greek and want to paste into your textbox... You won't like it to become "????????" in there


Anyway, it doesn't cost you anything to turn on the switch and either use the Unicode strings directly (L"some string") and call Unicode APIs (MessageBoxW), or use the "_T" apporach (_T("some string")). If anything, using Unicode sooner would force you to learn a better more portable way of code, like this:

char buffer[100];
GetData(buffer, sizeof(buffer) / sizeof(buffer[0]));

Instead of just

char buffer[100];
GetData(buffer, sizeof(buffer));

After doing this a couple time you'll start using special functions like

char buffer[100];
GetData(buffer, _countof(buffer);

And then after a while you'll take a look at your old programs and say "What was I thinking?" Since all your programs will be able to handle data in multiple languages, be able to talk to other programs over the Internet and run natively on x64 since you'll write them so cleanly that it would take only one switch change in your compiler...

Anyway, I just don't see a reason not to write Unicode-aware applications right now. You are not saving much by going with ANSI, but you are loosing the ability to reliably go through all the files in a folder if any of those files use Greek, Cyrillic or any other non-western characters in their names... That reason alone is worth the trouble (wait, what trouble? there is no trouble )

</rant end>

Tomasz, something is fishy with your results. Wrapping anything in try/catch wouldn't solve any problems... try/catch doesn't do anything for the code except to catch unexpected conditions (exceptions) and being able to handle them gracefully (like print meaningful message) instead of crashing...

That's it. I would look into the root of your problem because clearly it is not solved... Just my $0.02

[Tomasz]

I have come to a conclusion that the problem was not within my code but with my Windows configuration (it cries for reinstallation). Debugger generates error messages after every attempt to instatiate CorelDRAW. On the other hand compiled program works perfectly.

[SteveDude]

Originally Posted by Alex

<rant begin>
100% of my applications are Unicode. It's absolutely essential with this global economy to be able to read files in different languages. Even imagine you copy a string in Greek and want to paste into your textbox... You won't like it to become "????????" in there


Anyway, it doesn't cost you anything to turn on the switch and either use the Unicode strings directly (L"some string") and call Unicode APIs (MessageBoxW), or use the "_T" apporach (_T("some string")). If anything, using Unicode sooner would force you to learn a better more portable way of code, like this:

char buffer[100];
GetData(buffer, sizeof(buffer) / sizeof(buffer[0]));

Instead of just

char buffer[100];
GetData(buffer, sizeof(buffer));

After doing this a couple time you'll start using special functions like

char buffer[100];
GetData(buffer, _countof(buffer);

And then after a while you'll take a look at your old programs and say "What was I thinking?" Since all your programs will be able to handle data in multiple languages, be able to talk to other programs over the Internet and run natively on x64 since you'll write them so cleanly that it would take only one switch change in your compiler...

Anyway, I just don't see a reason not to write Unicode-aware applications right now. You are not saving much by going with ANSI, but you are loosing the ability to reliably go through all the files in a folder if any of those files use Greek, Cyrillic or any other non-western characters in their names... That reason alone is worth the trouble (wait, what trouble? there is no trouble )

</rant end>

Have to agree with Alex. There are actually other problems that can pop up, including some stability issues in some situations. Learned that the hard way.