Topic: Just a great place to be ...

[Hangman]

Hello all,
I don't get over here much any more, been busier than a one legged man in a butt kick'n contest.  But I digress.  I usually study out what I'm looking for and try to fix my problem(s) before coming over here for help.  Don't know why, the people here are excellent and well worth the time to associate with.

Anyway, on to a couple questions:
What is needed to create a dialog box with check boxes
I want to create an attributed detail bubble with text options below.
I want a left and right side, two lines of text below the bubble but I want to be able to, when editing the attribute - you know how the dialog box comes up to edit the lines - I want a checkbox for a left side TYP. & SIM. and a right side TYP. & SIM.
So that when the user checks the box, the text is automatically placed in the area specified.

Another question: (perhaps this does not belong here, but I am running this issue in a lisp and it is causing me problems).
Has anyone run into the problem of BIND, when putting details into a sheet and the arrowheads become either enormous or extremely small
We have a lisp routine for placing details onto a three-quarter inch D or E size sheet.  Works great.  Then, I wrote a lisp routine to bind that sheet when we send it out to clients.  After researching the problem, we have discovered that we can manually bind and still run into the problem.  I haven't noticed this issue on plans, but details are notorious for this problem.  Just wonder'n if any one else has run into this.  Does anyone else have a bind routine in a lisp

thanks guys.

[Jeff_M]

Hi Hangman, you should frequent this place more often.
Question 1, IMHO, is better suited to VBA. Dialogs are so much easier there than with lisp/dcl.

Question 2 is related to the Dimstyle, I believe. But I just tried to duplicate it and couldn't ...go figure. I know I have a small drawing here somewhere.....

Oh, wait! Here it is....if you BIND and Explode it seems to work OK, but if you Insert and explode, boom! The key is to always use a Unique Dimstyle name for your details, that way the parent drawing's setting for a name, such as Standard, won't override the detail's style.

[CAB]

Hangman,
JEff is correct Dialogs can be PITA.
But I don't find that a deal breaker & not too difficult if your needs are not exotic.
My suggestion would be to draw the dialog box as you want it to appear and post that drawing here.
That way we can see what you are after.

[Amsterdammed]

CAB,

You seem to share the preference of lisp over VBA with me.
But, although i go along with dcl/lisp pretty well, i have to say that the easy (what you see is what you get) way of VBA dialogs are great.

Bernd

[CAB]

Well the reason I prefer LISP is because I don't know VBA
I haven't had the time & desire to climb that mountain yet.
I have been doing some reading on ObjectArx but don't have the
compiler needed to play with this one.
A case of too much to do & too little time.

[JohnK]

Just to chime in here with one of my "rants"/"teachings"/"words of wisdom"/"what ever you want to call them".  (Im not ragging on anyone here, im just hoping to spur a discussion.)

Languages like VBA often do more harm then good to a up and coming developer. Its because of that "what you see is what you get" mentality; alot of times people think: "thats all there is to it". Well they are wrong. I think everyone will agree to this. If you dont ever know whats going on in the background...how can you work your way out of a sticky situation. Like the "teach a man to fish..." saying. VBA will only teach you that you need a 'pole' and 'bait' it dosent teach you a whole lot else.  And this isnt necessarily about VB(a) either  this is about IDEs too. When i write Cpp i use a raw compiler (just the compiler and my text editor.). because i want to see what the compiler thinks of my code. When i go to compile a file i know there insnt just interaction with the compiler i know there are TONS of things happening in the background. but that part of the key to this statement. The fact that i know there are alot of other steps to compiling is almost half the battle.

Well anyways, ill stop there and hope this spurs a bit of convo.

[Jeff_M]

When i go to compile a file i know there insnt just interaction with the compiler i know there are TONS of things happening in the background. but that part of the key to this statement. The fact that i know there are alot of other steps to compiling is almost half the battle.

Well anyways, ill stop there and hope this spurs a bit of convo.

OK, I'll bite..... Since I am a Civil Tech first, Land Surveyor second, CAD Dept. Manager third, IT guy fourth, and Janitor fifth, I don't care HOW the code gets compiled, or how the buttons on my form get their functionality...the fact that some Programmer, not a hack like me, made these tools available to me (and the rest of the world) allows me to create some mighty powerful and useful tools to make my job that much easier is what counts to ME. I use the IDE's whenever possible because I don't have the time nor inclination to learn the inner workings of a language. The tools have been put out there so we don't NEED to know those inner workings.

To say otherwise, IMHO, is akin to needing to draw some Construction drawings for the new Interstate; so to start off you go write your own CAD program, just so you know how it works, prior to starting the drawings. Me, I'd just plonk down in front of my Acad/LDD workstation and start cranking out the drawings.

I mean, how far do you take it? Have you assembled your own compiler so you know how it functions?

Don't get me wrong, I'm all for learning, expanding one's horizons, etc., and if your chosen profession is strictly programming then by all means make sure you know everuthing there is to know about the language you use.....but at the same time, do you include in your code snips of code from a toolbox of functions or do you rewrite the same functions everytime you need them? If you do use those toolbox functions, what's the difference in me using the IDE's form creator? It is, in essence, just a collection of oft used toolbox functions.......

One last thing, I HATE typing The last thing I want to do is use a format that will mean MORE typing for me......my typing skills, even after 20 years on these PC's, is still 3-4 fingers, hunt-n-peck...at probably a whopping 25-30 wpm.

Just this hacker's opinion......

[JohnK]

Good points Jeff.

For most thats good enough, and thats great! If that works for "you" then go for it! But for those that really like programing and get a kick outa seeing how the computer reacts/does/works/etc. i say stop take a step back and say: "Hold on a sec. When i type a word into my IDE, why does it turn yellow? And what makes it have to be like that?"  ...tinker.

No, i agree with you on that "need to know" issue (in fact im actualy using an ide right now for my lil "adding app". *blush*) But i think that everyone should try to break apart the IDE and see how it works (so to speak) once and a while. It will only teach you more about computers and such so you can then develop stronger/weaker apps. as the need arises.

Ive used this analogy before: When a pilot flys a plane, shouldnt (s)he kinda know how things work. I mean not to the point of being a mechanic but just so that they can do emergency work if necessary. (that kinda thing.)

No. *lol* ive never written a compiler.  Just read up on the process.

For the most part, ill re-assemble alot of procedures from scratch just cause its "easier" that way sometimes. (If i know what i want i can remove/add what i want on the fly.) Of course this all depends on my mood too. If im tired i dont want to do crap i'll just grab it and paste it in but  you get my point.

To be honest with ya. I would have to say using my Text editor would require less typing over the course of an app. For instance: If i create a C++ file in Vim. Ive set it up so that all i have to type when done all i have to type is this:
,w  <-- thats save
:make  <-- thats the command.
<alt + tab> to the prompt.
Then im done.

All the formating is done like in an IDE ...everything is the same just the interaction between the editor and the comp/intripter.

Well im outa here; i guess we have to go to a grad party now.

Later,

[Hangman]

Hey guys,
Thanks for the replies...  and sorry it has taken so long to get back to it.
That's interesting with the dim styles, we'll give it a shot.

As for the dialog box I was asking about, do a standard edit on an attributed text.  The dialog box that opens, that's what I want to add a few check boxes too.  I think it's a long shot though.  I guess I'd have to create a seperate edit attribute dialog box and command for the procedure.  

I'm in CABs boat, I don't know VBA and VL for that matter, I'm looking for a bunch of examples, different lisps of different tasks so I can get a feel of how VL works, the book just isn't helping me much.
Anyone in the mood to offer some suggestions / Lisps  

Thanks guys.

[Jeff_M]

As for the dialog box I was asking about, do a standard edit on an attributed text.  The dialog box that opens, that's what I want to add a few check boxes too.  I think it's a long shot though.  I guess I'd have to create a seperate edit attribute dialog box and command for the procedure.  

I'm in CABs boat, I don't know VBA and VL for that matter, I'm looking for a bunch of examples, different lisps of different tasks so I can get a feel of how VL works, the book just isn't helping me much.
Anyone in the mood to offer some suggestions / Lisps  
Thanks guys.

Yes, I think you are correct about the Attedit.

I was in yours & CAB's boat until 2 years ago. It was when I wanted to create a routine that would really benefit from having a dialog that I got started in VBA. It took a bit of reading in the help files, the autodesk newsgroups and forums such as this, before I even started. But after a while I finally figured out what I needed to make my application work. It wasn't pretty, codewise (heck, most will say that none of my code has ever looked good), but it worked as intended. And now I am not afraid to tackle most anything....not that I always succeed, but I'll usually give it a shot.

Suggestions? Sure....read a lot, try the samples in the Acad install, read some more, try to duplicate a routine that has been posted to a site, read some more, try coding your solution for ANYTHING that could be automated, keep reading. And most importantly, to me anyway, is do not think that you will become proficient by spending 1 or 2 hours a week 'trying it out'. Be committed and try to spend an hour or two each day either reading or coding.

And to top it off, by learning VBA I was able to pick up on VLisp/ActiveX that much faster. So intead of just setting out to learn one language I basically got 2 for 1.

And remember to ask questions....lots of them if need be. There are plenty of us around here eager to help you out.

[TR]

Just to chime in here with one of my "rants"/"teachings"/"words of wisdom"/"what ever you want to call them".  (Im not ragging on anyone here, im just hoping to spur a discussion.)

Languages like VBA often do more harm then good to a up and coming developer. Its because of that "what you see is what you get" mentality; alot of times people think: "thats all there is to it". Well they are wrong. I think everyone will agree to this. If you dont ever know whats going on in the background...how can you work your way out of a sticky situation. Like the "teach a man to fish..." saying. VBA will only teach you that you need a 'pole' and 'bait' it dosent teach you a whole lot else.  And this isnt necessarily about VB(a) either  this is about IDEs too. When i write Cpp i use a raw compiler (just the compiler and my text editor.). because i want to see what the compiler thinks of my code. When i go to compile a file i know there insnt just interaction with the compiler i know there are TONS of things happening in the background. but that part of the key to this statement. The fact that i know there are alot of other steps to compiling is almost half the battle.

Well anyways, ill stop there and hope this spurs a bit of convo.

Can you please tell me how I can reflect on a .NET assembly or browse the properties and methods of a COM server with vim? I'm pretty sure you can't.

For tasks like making a simple command line tool a text editor editor is fine but if you're dealing with automation and use of code that you don't have the source code to an IDE is priceless.

P.S..most IDE's with the exception of probably VBA show the compilers output.