yang686526

bad data generated by odgetsatfromproxy()
bad data generated by odgetsatfromproxy()
i'm trying to grab the sat data from a proxy entity of type "acadpart" and with the attached .dwg file, what i'm getting for sat data is gibberish. the sat file is attached (as a .txt). maybe it's binary sat (sab?) data? maybe the dwg file is from 2006? any ideas?
here's what my code in exprotocolextension() looks like:
void dump(oddbentity* pent, std(ostream) & os) const
{
// this will dump proxy entity graphics
//oddbentity_dumper::dump(pent, os);
dumpcommondata(pent, os);
if(pent->visibility() == oddb::kvisible)
{
// if the entity is of type acadpart, then dump the associated sat file
oddbproxyentityptr pproxy = pent;
odstring satstring;
if (pproxy->originalclassname() == "acadpart" &&
odgetsatfromproxy(pproxy, satstring))
{
odstring sn = buildacisfilename(); // my function to define a filename
odwrfilebuf wf(sn);
wf.putbytes(satstring.c_str(), strlen(satstring.c_str())*sizeof(char));
}
}
}
any help/advice would be appreciated
pete rimkus
cnc software
attached files
did you use toolkit v13 ?
i cannot reproduce it
try to find adpart entity by handle in odamfcapp and call 'save sat info to' dialog. it show you attached sat to adpart entity.
i thought i was using 1.13 but i'm not - i'm still at 1.12.4.
i'll build with 1.13 and i'll let you know what i find.
thanks,
pete

i verified that this does indeed work correctly in 1.13.02, but only in debug configuration. my app and all the release configurations of the odreadex c++ sample project will hang when reading the file i sent with the initial post. i've attached it again in case you need it
thanks in advance.
pete rimkus
cnc software, inc.
attached files (652.8 kb, 6 views)

last edited by pete rimkus; 28th june 2005 at 06:08 amfff">.
bump........
pete,
alex is working on it. we'll reply then the problem is solved.
sergey slezkin

pete,
problem is solved. fix will be available in next release/update.
sincerely yours,
george udov
thanks guys!
george & sergey,
i finally got a chance to look at this in 1.13.05 and it does indeed work for the file i sent, and for a couple others which had failed in the same place.
now i'm trying to attach another file which still fails. i get what appears to be a truncated sat file string. it looks good for @ 140kb, but then abruptly ends. the 'upload' is failing so i'll email it to support.
thanks,
pete rimkus
cnc software, inc.
last edited by pete rimkus; 27th september 2005 at 09:41 amfff">.
hi,
i have got files from you, but i cannot reproduce your problem. i have tested debug and release 1.13.* i use mfcapp to load files and got sat info from adpartproxy... for example, i have found two adpart in assy valve.dwg, in u1 and u4 blocks, both return valid sat (u4 has clear sat). also i have used readex (rel&debug) to read your files - it is not hang... please give me more information about problem...
alex,
it is indeed extracting sat data for the solid on *u1, but that data is incomplete.
i added the following...
odstring sn = "c:\\test.sat";
odwrfilebuf wf(sn);
wf.putbytes(satstring.c_str(), strlen(satstring.c_str())*sizeof(char));
to exprotocolextension.cpp's oddbproxyentity_dumper::dump() function after the 'if' test and and the resultant .sat file is incomplete. can you try this?
pete
also: i've attached the resultant sat file. there's an error generated when i try to attach the dwg file
attached files (43.5 kb, 6 views)

last edited by pete rimkus; 30th september 2005 at 09:12 amfff">.
hi,
i have found bug in our mathematics (conversion from 20800 to v4). i'll try to fix it.
ps:
there is no bug here when you convert sat to >= 500.
alex,
thanks.
based upon your last sentence, is there a way for me to work around the problem and get good sat data? i don't see where i have any control over what sat version will be returned from odgetsatfromproxy(). maybe you know a secret?
pete
toolkit_export bool odgetsatfromproxy(const oddbproxyentityptr& adpart, odstring& sat);
toolkit_export bool odgetsatfromproxy(const oddbproxyentityptr& adpart, odmodelergeometryptr& pmodelergeometry);
you can use second variant, mfcapp used it in constructor of cacissavedialog class.
ok - i'll give that a shot.
thanks
pete