yang686526

simple tutorial
simple tutorial
i'm a vb6 and c# programmer. i've looked at the odamfcapp and frankly am having a hard time getting my head around the simple use of the libraries. i basically want to open a dwg file and show it in a vb6 or .net picturebox, change background color from black to white, zoom, add a text entity, print the drawing, and remove the text entity. it would also be nice to iterate through the entities.
i'm sure there are ways to do all of these things, but i'm confused in trying to follow how this is done in the (to me) complex examples. i sense that i need to make calls on the dlls in much the same way as making windows api calls, but there are many dlls, variable type issues, etc.
can anyone point me in the right direction?
it seems that without some knowledge of c++, it is amost impossible to accomplish that task from c#/vb.
having some skills though, it would be easier to create com wrapper around the necessary functionality, than to call c++ dlls directly.
if not for the printing, i would have suggested using our viewx control instead. but there is no printing, and probably will not be.
vladimir
i do have some familiarity with c++. what i'm having trouble with is things like having five opendocumentfile methods, some of which call each other, some of which require a string and a boolean, some just a string. when i search for opendocumentfile in the help file i get no matches. it looks like the call to opendocumentfile returns a pointer to a cdocument which i'd probably use for getting it into a picturebox, changing the backcolor, adding a text entity and printing. a bonus would be to iterate through entities looking for text entities from which to derive the title. i don't want to do many high-level tasks.
it appears the dlls have quite a bit of robust functionality. i guess i'm looking for some of that impressiveness in the documentation.
if i knew which dlls/calls to focus on i'd gladly go through the tedium of wrapping the calls in a vb com dll which i'd use directly in vb6 and through com interop in c#.
quote:
originally posted by wvk
it seems that without some knowledge of c++, it is amost impossible to accomplish that task from c#/vb.
having some skills though, it would be easier to create com wrapper around the necessary functionality, than to call c++ dlls directly.
if not for the printing, i would have suggested using our viewx control instead. but there is no printing, and probably will not be.
odamfcapp is too complex sample for a beginner indeed.
first of all you may look at odvectorizeex sample - it dumps vectorized contents of the file to the console.
then you may look at the sample singledoc.
vladimir
another beginner who is struggling...
i agree with those who are frustrated by the lack of appropriately simple examples or a good beginner-level introduction. actually there is a lack of *any* documentation except for the useless-but-pretty computer-generated stuff that is supplied.
i've been doing this stuff (cad programming) since 1972, and have written all sorts of translators (iges, dxf, sirlin-based, autodirect/marcomp-based, etc.) and this is far and away the most difficult to figure out. it sure looks impressive (if all that complexity actually does anything), but us peons in the real world have jobs to do, usually pretty simple ones, and we just want to get them done.
here are a few suggestions:
1. like almost everyone has cried out for, give us a *simple* example. how about a program that opens a no-frills drawing file, and lists all the text-entity strings in it? the program should be for a single platform, and should contain *only* what a user trying to develop a bone-simple application for that platform *must* do to get it working.
2. comment the examples. examples are supposed to explain things. it should be possible for a beginner to read the examples and understand what is going on. it also wouldn't hurt to explain some of the more obscure quirks of c++, since not all of us have cs doctorates and some are even using c#.
3. break the "examples" into two parts: sample programs, and reference implementations of required user-supplied code. it looks kind of like the whole concept of "examples" got loose during development, and it became a place to write things like odfilebuf which are really part of the dwgdirect code but which must be supplied as source to allow user changes. i keep reading postings suggesting that users might consider using odfilebuf "until they write their own implementation", which suggests that the delusion that "examples" are just that is still alive and well among the dwgdirect developers. as one of the rubes who want to use this stuff to actually get work done, i might humbly propose that pretty much everything in the exservices directory (and perhaps more... i still haven't gotten to the point of sucessfully compiling an application) be pulled out of examples and supplied as ready-to-use code (maybe even lib files) for those who only need standard functionality. anyone who needs to modify them still could, but simple applications (and simple examples(!)) would get a whole lot simpler.
4. write a tutorial. yes i know, there's never time for writing documentation, but if you look at your job as making our little corner of the cad world a better place, you can get a lot of leverage by enabling the users and potential users of dwgdirect to use it effectively. empowering users (by giving them adequate documentation) can have a much bigger effect than writing whatever code is keeping you from writing documentation. how many nifty applications never got written because the developer gave up two weeks into trying to untangle exservices?
i'm quite aware of the tremendous amount of work that has gone into dwgdirect, and i don't want to sound like a whiner -- i've been there and i know how hard it is to balance everything as a large project keeps growing. i'd offer to help but i'm still too much of a newbie to contribute much. i am going through parts of the sample code and commenting it, to help me understand it, and if it looks like it might be useful to others i'll post it.
i'd also appreciate a whack upside the head if i've got this all wrong.
-jimc
last edited by exeye; 27th july 2005 at 12:50 amfff">. reason: correcting terminology
first of all, thank you for your post. it is very reasonable and i can agree with almost every point. my comments below.
about documentation:
some time we had some lame excuse, for not having sound documentation - we were saying: "dd is mostly compatible to arx, so refer to arx help - it is complete enough." obvously it is not correct behaviour, and several months ago oda hired a man for full time doc-writing, and he is now rapidly improving this automatically generated stuff, you so contemptuously mentioned
about separating samples and stuff:
well indeed separating user-overridable code and examples is an option to be considered. it will be discussed, and maybe implemented
about simple examples:
sure, some examples grew large, mostly because some concepts are easier to illustrate in cad-program-like environment. because of that, our odamfcapp sample has grown to almost a product (exept the interface, of course)
there are though 3 canonically simple examples, illustrating work with database: odreadex,odwriteex, and odvectorizeex
"sat*" samples are also not that complex
generally speaking, almost all the "*ex" samples are simple enough, maybe poorly commented. lack of comments is normal in production code - code should be readable without comments: "if you cannot read code - refactor it". this rule of course should not be applied to samples, but it is already next topic:
about commenting samples and tutorial:
sure you are right about frustration, newbies, c# users, etc.
there is a difficulty though - i know very few programmers that were good teachers at the same time - it seem to require quite a different thinking type and skill. all the other reasons still apply, like no time to document, implementing features (required by users), fixing bugs (first priority always), etc..
sure it is no excuse, and moreover, nothing new is said, i fear
quote:
i'd offer to help but i'm still too much of a newbie to contribute much. i am going through parts of the sample code and commenting it, to help me understand it, and if it looks like it might be useful to others i'll post it.
you seem to have (not so common) ability to express yourself clearly, and i think your comments to samples will be welcome.
if you will have the time to write a tutorial it would be great, though it is an impudence to ask that much
vladimir

the number of posts in this forum would drop by 50% if you provide a good tutorial and you would save time in replying to these...so a win-win situation for all...so when can we expect some results on this front...thanks