ObjectARX
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RealDWG 2014 app returns different results on different machines

8 REPLIES 8
Reply
Message 1 of 9
swl773
815 Views, 8 Replies

RealDWG 2014 app returns different results on different machines

I've written a RealDWG 2014 C# .NET (VS2010 sp1) app, loosely based on the sample .net app, and am basically looping through the object ids in the block table record and pulling more information out of certain objects, specifically 'AcDbBlockReference' and 'AcDbRasterImage'.  I list the dxfname and the object name of every one as I go.

 

Running the exe on my development machine (windows 7, 32bit), when I have raster images in a drawing, I get objects that are a 'AcDbRasterImage'. 

When I move the app to another machine (windows 2008 server, 64bit), everything returned is exactly the same except for the 'AcDbRasterImage' objects. In their place  in the output listing are objects with the DXF name empty and the object name 'AcRxObject.' 

I tried retrieving the object id and casting it to a RasterImage, but that didn't fly.

 

Any idea why on one machine it is a AcDbRasterImage and on another a AcRxObject? Like I say, all the other output is exactly the same. And both machines have the same RealDWG and the same application...

 

Thanks for any help.

 

Steve

 

P.S. I am writing this .NET app to replace an old, hard to maintain, C++ app. It, like the C# app, was compiled on the 32bit machine, and moved to the 64bit server and run in both places on the same drawing. Unlike the C# app, it identifies the object as AcDbRasterImage on both machines. 

8 REPLIES 8
Message 2 of 9
artc2
in reply to: swl773

Is the acismobj19.dbx module loaded into your app when the drawing is being processed.  If it is not, then that would prevent your image entities from being treated as images.

Message 3 of 9
swl773
in reply to: artc2

It's usually pretty quick to complain if it can't find something it needs to load, and there are no errors or error messages. I'll check tomorrow and make sure that particular module is in the path and in the executable's directory.
Thanks for the suggestion. I'll let you know.
Message 4 of 9
artc2
in reply to: swl773

Having it in the path is not enough.  You also need to either have your application explicitly load it, or else the necessary demand load registry entries must be in place so that when the image entity is detected during drawing open, RealDWG can demand load the application.

Message 5 of 9
swl773
in reply to: artc2

Well, artc2 was right on it.  Thanks a lot!! 

 

I found 3 ways to make it work. 

 

1) install the full RealDWG 2014 on every machine.  I don't know what this did, maybe put the proper entries in the registry, but the app recognized the block as AcDbRasterImage when I installed the whole thing.  I don't have but a few servers to install the app on, so I could do this, but not my preferred method.

 

2) Put this statement in the source before doing any raster processsing:

(new RasterImage()).Dispose();

This causes the correct module(s) to be loaded before the program tries to identify the block. 

 

3) Put these statments in.  They do the same thing as (2), but do it explicitly. 

    DynamicLinker dl = SystemObjects.DynamicLinker;

   dl.LoadModule("acismobj19.dbx",false, false); 

I like this one because it is obvious what is going on.  I don't like it because it willrequire changing when the next RealDWG changes the name of the module being loaded. 

                                               

Message 6 of 9
StephenPreston
in reply to: swl773

For #1, you shouldn't have to install the full RealDWG. You just need to add the correct merge modules to your own installer. You are creating an installer to deploy your app, aren't you? Simply copying a RealDWG application won't correctly setup your registry.

 

#3 is the method I used to use in ObjectARX way back when.

Cheers,

Stephen Preston
Autodesk Developer Network
Message 7 of 9
swl773
in reply to: StephenPreston

Installing the full RealDWG is overkill, and I suspect that it does what an installer would do and more from a registry perspective.

 

#3 is the method I used in RealDWG way back when too.  I looked at my C++ program and it's doing that.  The problem nowadays is that even if I do that and deploy with all the modules in the RealDWG 2014 root, it's not enough.  I have to copy the entire RealDWG 2014 directory structure and put it in the path.  So, the program plus the ISM module load plus the directory structure plus the path change, and it works.  Not exactly elegant, but I have 7 boxes to put it on, so I can survive a manual install.  But with all that, it's a lot more complicated than it used to be - deploying the exe with a few dlls. 

 

And no, I'm sure you can tell from all that, I'm not creating an installer.  I'll give that a try next.  I've run through it once quickly and didn't see a place to set properties or INSTALL_DIRs and such.  Do you have a tutorial or example on how to create an installer for a RealDWG app? 

 

Thanks

 

Steve

Message 8 of 9
swl773
in reply to: swl773

You can create a RealDWG specific installer by following the step by step instructions found in the the help file arxdoc.chm.  The help file is located in \RealDWG 2014\Docs.  Go to the topic RealDWG Readme -> Tips and Techniques -> Creating a RealDWG Installer. 

 

There is also a section in the Tips and Techniques on Raster Images.

If you wish to write an RealDWG 2014 host application that manipulates raster entities, you must first link to the Imaging Support Module (ISM) DBX, then have your application explicitly load that DBX file (for example, using AcRxDynamicLinker::loadModule()) before attempting to call any of the raster APIs. 

If you read a DWG file that contains raster entities, RealDWG 2014 will attempt to pull in ATIL dlls upon encountering an AcDbRasterImage entity in the drawing file.

 

Although I am only reading a drawing file, I found that I still had to explicity load the image module with either

(new RasterImage()).Dispose();

or

DynamicLinker dl = SystemObjects.DynamicLinker;

dl.LoadModule("acismobj19.dbx",false, false);  .

 

RealDWG 2014 may have attempted to pull in ATIL dlls (as it states in the Raster Image section), but it must not have been successful.  No matter.  It is a small price to pay to have it work. 

 

Message 9 of 9
StephenPreston
in reply to: swl773

Hi Steve,

 

The only tutorial I can point you to is this one posted on the TechSoft 3D website, but its a bit old now: http://download.autodesk.com/media/adn/DevTV-Introduction-to-RealDWG-Programming/ - it includes a piece on creating the installer. There is also a section on installer requirements in the RealDWG documentation that is included in your installation. However, the bottom line is that you just have to create an installer for your application, and then merge into your MSI installer some of the (MSM) merge modules provided in the SDK. Which you use depend on what functionality you're accessing.

 

Please don't deploy RealDWG applications to your customers without creating your own installer incorporating the required merge modules. Simply copying the files is not sufficient to correctly setup RealDWG.

Cheers,

Stephen Preston
Autodesk Developer Network

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost