Patterns for subroutine library

[Anonymous]

I am starting to develop a subroutine library for .net, and would like some opinions on:
1) do most people just write all the transaction code in their main code, or do they write subs to do things like draw a
line or select whatever?
I am thinking I need to make simple user functions like DrawLine or DrawPline to hide all the transaction stuff.

2) Is it better to pass in a transaction object outside the functions like Drawline? I have heard its slow to
constantly grab a transaction and close it. If I need to draw multiple things, I could reuse that trans object.
What are the dangers of doing this (assuming I do the basics right like dispose and all)?

3) anyone started such an effort, and could they share some stuff?

I feel like we are back in the days of when Maximizing Autolisp for R12 was written. Lisp was catching on and every
company started to have a collection of lisps, but very few people were good at authoring autolisp.

That book explained how to make user functions to wrap the bare lisp functions.
I remember buying it with my own money when I was just out of college. My company would not pay for it but it was worth
it. The arx help files (and NG's) seem to be the guiding light for now.
thanks

James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

dang, I'm getting the cold shoulder now. I must have mentioned lisp (oops, hate it when I do that) one too many
times...

James Maeding
|>I am starting to develop a subroutine library for .net, and would like some opinions on:
|>1) do most people just write all the transaction code in their main code, or do they write subs to do things like draw a
|>line or select whatever?
|>I am thinking I need to make simple user functions like DrawLine or DrawPline to hide all the transaction stuff.
|>
|>2) Is it better to pass in a transaction object outside the functions like Drawline? I have heard its slow to
|>constantly grab a transaction and close it. If I need to draw multiple things, I could reuse that trans object.
|>What are the dangers of doing this (assuming I do the basics right like dispose and all)?
|>
|>3) anyone started such an effort, and could they share some stuff?
|>
|>I feel like we are back in the days of when Maximizing Autolisp for R12 was written. Lisp was catching on and every
|>company started to have a collection of lisps, but very few people were good at authoring autolisp.
|>
|>That book explained how to make user functions to wrap the bare lisp functions.
|>I remember buying it with my own money when I was just out of college. My company would not pay for it but it was worth
|>it. The arx help files (and NG's) seem to be the guiding light for now.
|>thanks
|>
|>James Maeding
|>Civil Engineer and Programmer
|>jmaeding - athunsaker - com
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

Hi James,
You asked for opinions, so...

>1) do most people just write all the transaction code in their main code,
>or do they write subs to do things like draw a
>line or select whatever?
>I am thinking I need to make simple user functions like DrawLine or
>DrawPline to hide all the transaction stuff.
Regardless of language it is generally a good idea to break up your code
into smaller single purpose procedures that hide complexity. In .NET, and
other platforms that support classes, you can extend that thought to
creating small cohesive classes as well.

>2) Is it better to pass in a transaction object outside the functions like
>Drawline? I have heard its slow to
>constantly grab a transaction and close it. If I need to draw multiple
>things, I could reuse that trans object.
>What are the dangers of doing this (assuming I do the basics right like
>dispose and all)?
Don't base your decision on how to use Transactions based on how you think
it will affect performance. Base it on how the code needs to function. If
you need to draw multiple items and have them all controlled by a single
Transaction, then by all means pass the Transaction from top level to lower
level procedures. Don't forget that you can also nest Transactions.

>3) anyone started such an effort, and could they share some stuff?
I think that your talking about creating a simplified interface where
instead of starting a Transaction, opening the BlockTable, then opening the
modelspace BlockTableRecord, then adding a line to it, and the transaction,
and then commiting and disposing of the transaction, you just make a single
call to a function to pass in two endpoints to add the line; kind of like
the ActiveX API? Is that what you're asking? If so, then no, I personally
haven't done that.

>I feel like we are back in the days of when Maximizing Autolisp for R12 was
>written. Lisp was catching on and every
>company started to have a collection of lisps, but very few people were
>good at authoring autolisp.
I'm pretty sure that AutoLISP had caught on before R12 🙂

>The arx help files (and NG's) seem to be the guiding light for now.
The ARX SDK and our peers here and elsewhere are definitely guiding lights.
If you're serious about writing code for Autodesk products then I'd also
recommend joining ADN.

[Anonymous]

Thanks Bobby.
I'll make my library and see how it goes.

Bobby C. Jones
|>Hi James,
|>You asked for opinions, so...
|>
|>>1) do most people just write all the transaction code in their main code,
|>>or do they write subs to do things like draw a
|>>line or select whatever?
|>>I am thinking I need to make simple user functions like DrawLine or
|>>DrawPline to hide all the transaction stuff.
|>Regardless of language it is generally a good idea to break up your code
|>into smaller single purpose procedures that hide complexity. In .NET, and
|>other platforms that support classes, you can extend that thought to
|>creating small cohesive classes as well.
|>
|>>2) Is it better to pass in a transaction object outside the functions like
|>>Drawline? I have heard its slow to
|>>constantly grab a transaction and close it. If I need to draw multiple
|>>things, I could reuse that trans object.
|>>What are the dangers of doing this (assuming I do the basics right like
|>>dispose and all)?
|>Don't base your decision on how to use Transactions based on how you think
|>it will affect performance. Base it on how the code needs to function. If
|>you need to draw multiple items and have them all controlled by a single
|>Transaction, then by all means pass the Transaction from top level to lower
|>level procedures. Don't forget that you can also nest Transactions.
|>
|>>3) anyone started such an effort, and could they share some stuff?
|>I think that your talking about creating a simplified interface where
|>instead of starting a Transaction, opening the BlockTable, then opening the
|>modelspace BlockTableRecord, then adding a line to it, and the transaction,
|>and then commiting and disposing of the transaction, you just make a single
|>call to a function to pass in two endpoints to add the line; kind of like
|>the ActiveX API? Is that what you're asking? If so, then no, I personally
|>haven't done that.
|>
|>>I feel like we are back in the days of when Maximizing Autolisp for R12 was
|>>written. Lisp was catching on and every
|>>company started to have a collection of lisps, but very few people were
|>>good at authoring autolisp.
|>I'm pretty sure that AutoLISP had caught on before R12 🙂
|>
|>>The arx help files (and NG's) seem to be the guiding light for now.
|>The ARX SDK and our peers here and elsewhere are definitely guiding lights.
|>If you're serious about writing code for Autodesk products then I'd also
|>recommend joining ADN.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

[Anonymous]

James, you may want to check out the MgdDbg project that James Awe created.
It has a number of helper classes that you may find interesting.
--
Bobby C. Jones

"James Maeding" wrote in message
news:5174001@discussion.autodesk.com...
Thanks Bobby.
I'll make my library and see how it goes.

Bobby C. Jones
|>Hi James,
|>You asked for opinions, so...
|>
|>>1) do most people just write all the transaction code in their main code,
|>>or do they write subs to do things like draw a
|>>line or select whatever?
|>>I am thinking I need to make simple user functions like DrawLine or
|>>DrawPline to hide all the transaction stuff.
|>Regardless of language it is generally a good idea to break up your code
|>into smaller single purpose procedures that hide complexity. In .NET, and
|>other platforms that support classes, you can extend that thought to
|>creating small cohesive classes as well.
|>
|>>2) Is it better to pass in a transaction object outside the functions
like
|>>Drawline? I have heard its slow to
|>>constantly grab a transaction and close it. If I need to draw multiple
|>>things, I could reuse that trans object.
|>>What are the dangers of doing this (assuming I do the basics right like
|>>dispose and all)?
|>Don't base your decision on how to use Transactions based on how you think
|>it will affect performance. Base it on how the code needs to function.
If
|>you need to draw multiple items and have them all controlled by a single
|>Transaction, then by all means pass the Transaction from top level to
lower
|>level procedures. Don't forget that you can also nest Transactions.
|>
|>>3) anyone started such an effort, and could they share some stuff?
|>I think that your talking about creating a simplified interface where
|>instead of starting a Transaction, opening the BlockTable, then opening
the
|>modelspace BlockTableRecord, then adding a line to it, and the
transaction,
|>and then commiting and disposing of the transaction, you just make a
single
|>call to a function to pass in two endpoints to add the line; kind of like
|>the ActiveX API? Is that what you're asking? If so, then no, I
personally
|>haven't done that.
|>
|>>I feel like we are back in the days of when Maximizing Autolisp for R12
was
|>>written. Lisp was catching on and every
|>>company started to have a collection of lisps, but very few people were
|>>good at authoring autolisp.
|>I'm pretty sure that AutoLISP had caught on before R12 🙂
|>
|>>The arx help files (and NG's) seem to be the guiding light for now.
|>The ARX SDK and our peers here and elsewhere are definitely guiding
lights.
|>If you're serious about writing code for Autodesk products then I'd also
|>recommend joining ADN.
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com