yang686526

wingdi_2.06_9.gs on windows server 2003
wingdi_2.06_9.gs on windows server 2003
hello
i've implemented an activex-control which converts dxf-files into bmp-files. on windows xp it works well (after sorting out some problems here in the forum). on a windows server 2003 plattform, the bmp-export fails. i suspect that it has something to do with the wingdi-module that is used for rasterizing and creating the bitmap. all other functions of the activex-control work alright, so it has nothing to do with com or registering the dll.
unfortunately i do not have the possibility of debugging the application on windows server 2003, so i can not tell you what kind of oderror occurs. as i said before, it works on windows xp.
does anyone know if windows server 2003 lacks certain resources that are needed for the wingdi-module to work properly?
edit:fff"> are there certain graphiccards and/or -drivers needed for the wingdi-module to work?
any hints are welcome. thanks.
martin
ps: here is the code used for bmp-export (yes, i've posted this code before, but in a different context...)
code:
int commonfunctions::writebmp( oddbdatabaseptr pdb, long resolution, odstring targetfile )
{
int rcode = rc::r_rstdev;
try{
//code from cmd_bmpout
//odgsmoduleptr pgs = odrxdynamiclinker()->loadmodule(dd_t("winopengl_2.06_9.gs"), false);
//odgsmoduleptr pgs = odrxdynamiclinker()->loadmodule(dd_t("windirectx_2.06_9.gs"), false);
odgsmoduleptr pgs = odrxdynamiclinker()->loadmodule(dd_t("wingdi_2.06_9.gs"), false);
//odgsmoduleptr pgs = odrxdynamiclinker()->loadmodule(dd_t("winbitmap_2.06_9.gs"), false);
odgsdeviceptr pdevice = pgs->createbitmapdevice();
odgicontextfordbdatabaseptr pctx = odgicontextfordbdatabase::createobject();
pctx->setdatabase(pdb);
// extents of active layout
pdevice = oddbgsmanager::setupactivelayoutviews(pdevice, pctx);
odabstractviewpeptr pdeviceview;
odgsviewptr pdv;
odrxobjectptr playoutview;
if (!pdb->gettilemode())
{ // paper space
pdv = odgspaperlayouthelperptr(pdevice)->overallview();
pdeviceview = pdv;
oddblayoutptr playout = pdb->currentlayoutid().safeopenobject();
oddbobjectid overallvpid = playout->overallvportid();
oddbviewportptr pactivevp = overallvpid.safeopenobject();
playoutview = pactivevp;
}
else
{ // model space
pdv = odgsmodellayouthelperptr(pdevice)->activeview();
pdeviceview = pdv;
oddbviewporttableptr pvpt = pdb->getviewporttableid().safeopenobject();
oddbviewporttablerecordptr pactivevp = pvpt->getactiveviewportid().safeopenobject();
playoutview = pactivevp;
}
// get extents from current layout
odgeboundblock3d bbox;
odabstractviewpeptr playoutviewpe(playoutview);
playoutviewpe->viewextents(playoutview, bbox);
pdeviceview->zoomextents(pdv, &bbox);
int ncolorbits = 1;
pdevice->properties()->putat("bitperpixel", odrxvariantvalue(oduint32(ncolorbits)));
odcolorref bg = odrgb(255,255,255); // palette background
pctx->setpalettebackground(bg);
const odcolorref* palette = odcmacadpalette(bg);
odgspalette ppalcpy;
ppalcpy.insert(ppalcpy.begin(), palette, palette+256);
ppalcpy[0] = bg;
pdevice->setlogicalpalette(ppalcpy.asarrayptr(), 256);
double width = bbox.maxpoint().x - bbox.minpoint().x;
double height = bbox.maxpoint().y - bbox.minpoint().y;
double x = ( width/25.4 ) * resolution;
double y = ( height/25.4 ) * resolution;
//round
long xsize = (long)floor(x+0.5);
long ysize = (long)floor(y+0.5);
odgsdcrect gsrect(0, xsize, ysize, 0 );
pdevice->onsize(gsrect);
pctx->setplotgeneration(1);
pdevice->setbackgroundcolor(bg);
pdevice->update();
rcode = rc::r_wrtbmp;
savebitmap( odgirasterimageptr(pdevice->properties()->getat("rasterimage")), targetfile );
rcode = rc::r_ok;
} catch( oderror e ){
odstring s = e.description();
odresult r = e.code();
oderrorcontext * ec = e.context();
}
return rcode;
}
last edited by martin.affolter@ntb.ch; 15th october 2008 at 08:53 amfff">.

hi,
unfortunately, we don't have any information about problems onto windows server 2003 platform, so any debugging or tracing of founded problem will be very helpful for us. wingdi rendering device in principle is driver independent, because windows hides any driver-dependent functionality inside gdi kernel and make software handling silently if hardware not support any operation. gdi only makes some limitations: maximum context size, color depth and etc.
maybe the problem occurs in case of incorrect access permissions settings?
the problem only with wingdi, or opengl and other devices faults too?
on windows server 2003 we get an "extended error" (311). the odrxdynamiclinker fails to load the module wingdi_2.06_9.gs. can you tell me where the odrxdynamiclinker looks for the module?
as i explained in the previous post, dwgdirect is used by an activex-control. the dll containing the control lies in the same directory as all the dwgdirect dlls and modules. i am not sure, which directory the dll is executed in, it does not seem to be the same directory the dll lies in...
would it help to add the directory containing the modules to the path-variable?
martin
the problem may be manifest related. 2003 server treats embedded manifest and external manifest differently.
you may try to add an external manifest to wingdi*.gs
wingdi_2.06_9.gs.manifest:
code:
<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestversion='1.0'>
<trustinfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedprivileges>
<requestedexecutionlevel level='asinvoker' uiaccess='false' />
</requestedprivileges>
</security>
</trustinfo>
<dependency>
<dependentassembly>
<assemblyidentity type='win32' name='microsoft.vc90.crt' version='9.0.21022.8' processorarchitecture='x86' publickeytoken='1fc8b3b9a1e18e3b' />
</dependentassembly>
</dependency>
</assembly>
vladimir
external manifest files needed on windows server 2003
we added the manifest-file you provided to the directory and the module could be loaded. the problem seems to be solved. we've spent quite some time trying to find the reason... will you provide external manifest-files for the other modules too?
thanks for your help
martin
in your case all loadable modules would have identical manifests.
perhaps you mean why we don't distribute our dll with manifests included?
actually, we can't do it, because manifest contents depend on the runtime version the application is linked with (thanks microsoft). if you were working on vs w/o sp1 installed, manifest contents would be different.
usually linking w/o manifest works fine for all the clients, but your case is more complicated.
all we can do is document the case, and include the question in faq.
vladimir
last edited by vkalinin; 29th october 2008 at 06:50 amfff">.