OberonPlace.com Forums  

Go Back   OberonPlace.com Forums > Developer Forums > VBA > CorelDRAW/Corel DESIGNER VBA

Reply
 
Thread Tools Search this Thread Display Modes
  #1  
Old 18-03-2009, 16:23
Tomasz Tomasz is offline
Junior Member
 
Join Date: Aug 2006
Posts: 21
Default Problem with VC++ and CDR X4

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:

Code:
#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:
Code:
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:
Code:
    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
Reply With Quote
  #2  
Old 19-03-2009, 09:45
jemmyell jemmyell is offline
Senior Member
 
Join Date: Jan 2005
Location: Orange County, California, USA, Earth, Solar System, Milky Way Galaxy
Posts: 157
Default Are you recompiling with the X4 typelibs?

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
__________________
-James Leonard
CNC Inlay Guy - www.CorelDRAWCadCam.com
Reply With Quote
  #3  
Old 19-03-2009, 09:56
Alex's Avatar
Alex Alex is offline
Administrator
 
Join Date: Nov 2002
Posts: 1,940
Blog Entries: 4
Default

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

Code:
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).

Quote:
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
Reply With Quote
  #4  
Old 19-03-2009, 11:23
jemmyell jemmyell is offline
Senior Member
 
Join Date: Jan 2005
Location: Orange County, California, USA, Earth, Solar System, Milky Way Galaxy
Posts: 157
Default

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
__________________
-James Leonard
CNC Inlay Guy - www.CorelDRAWCadCam.com
Reply With Quote
  #5  
Old 19-03-2009, 13:56
Tomasz Tomasz is offline
Junior Member
 
Join Date: Aug 2006
Posts: 21
Default

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
Reply With Quote
  #6  
Old 19-03-2009, 16:34
jemmyell jemmyell is offline
Senior Member
 
Join Date: Jan 2005
Location: Orange County, California, USA, Earth, Solar System, Milky Way Galaxy
Posts: 157
Default

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
__________________
-James Leonard
CNC Inlay Guy - www.CorelDRAWCadCam.com
Reply With Quote
  #7  
Old 19-03-2009, 22:50
Alex's Avatar
Alex Alex is offline
Administrator
 
Join Date: Nov 2002
Posts: 1,940
Blog Entries: 4
Default

Quote:
Originally Posted by jemmyell View Post
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:

Code:
char buffer[100];
GetData(buffer, sizeof(buffer) / sizeof(buffer[0]));
Instead of just

Code:
char buffer[100];
GetData(buffer, sizeof(buffer));
After doing this a couple time you'll start using special functions like

Code:
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

Last edited by Alex; 04-04-2009 at 10:56.
Reply With Quote
  #8  
Old 04-04-2009, 07:49
Tomasz Tomasz is offline
Junior Member
 
Join Date: Aug 2006
Posts: 21
Default

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.
Reply With Quote
  #9  
Old 14-04-2009, 04:52
SteveDude SteveDude is offline
Senior Member
 
Join Date: Dec 2005
Location: Salina, Kansas USA
Posts: 149
Default ...

Quote:
Originally Posted by Alex View Post
<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:

Code:
char buffer[100];
GetData(buffer, sizeof(buffer) / sizeof(buffer[0]));
Instead of just

Code:
char buffer[100];
GetData(buffer, sizeof(buffer));
After doing this a couple time you'll start using special functions like

Code:
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.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -5. The time now is 00:44.


Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Copyright © 2011, Oberonplace.com