.NET
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Insert Block C# (eventually would like to put block on specific layer)

27 REPLIES 27
Reply
Message 1 of 28
joelkarr
1938 Views, 27 Replies

Insert Block C# (eventually would like to put block on specific layer)

I am trying to use C# to insert a block into an AutoCAD drawing at point 0,0

when I run the code I get "(2126748928)Temperature Switch - Imperial inserted" in the command line but can not see a block at point 0,0

any ideas on to why this code doesn't work? Does the fact that it is a dynamic block effect the code?

Thanks in advance



using System;

using Autodesk.AutoCAD;

using Autodesk.AutoCAD.Runtime;

using Autodesk.AutoCAD.Geometry;

using Autodesk.AutoCAD.ApplicationServices;

using Autodesk.AutoCAD.DatabaseServices;

using Autodesk.AutoCAD.EditorInput;

using System.Collections.Generic;
using System.IO;


namespace BlockImport
{

public class BlockImportClass
{

[CommandMethod("BI")]
public void InsertBlock()
{
Document doc = Application.DocumentManager.MdiActiveDocument;
Database db = doc.Database;
Editor ed = doc.Editor;
try
{

//Test block name and point (final version will use user input)
string nameOfBlock = "Temperature Switch - Imperial";
Autodesk.AutoCAD.Geometry.Point3d pos = new Point3d(0, 0, 0);
// Get the current working database
Transaction tr = db.TransactionManager.StartTransaction();
// Then open the block table and check the
// block definition exists
BlockTable bt = (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead);
if (!bt.Has(nameOfBlock))
{
ed.WriteMessage("\nBlock not found.");
}
else
{
ObjectId bdId = bt[nameOfBlock];
Point3d pt = new Point3d(0, 0, 0);
// Create the block reference
BlockReference br = new BlockReference(pt, bdId);
//Add block reference to model space table
BlockTableRecord btrms = (BlockTableRecord)tr.GetObject(bt[BlockTableRecord.ModelSpace], OpenMode.ForWrite);
btrms.AppendEntity(br);
tr.AddNewlyCreatedDBObject(br, true);
//Graphics Flush so block will be visible
doc.TransactionManager.QueueForGraphicsFlush();
ed.WriteMessage(bdId + nameOfBlock + " inserted");
}


//Clean up transaction

tr.Commit();
tr.Dispose();
}
catch (Autodesk.AutoCAD.Runtime.Exception ex)
{
ed.WriteMessage("\nError during copy: " + ex.Message);
}
}

}

}
27 REPLIES 27
Message 2 of 28
chiefbraincloud
in reply to: joelkarr

I use VB, so I translated it...

This line gave me a compile error "ed.WriteMessage(bdId + nameOfBlock + " inserted");"

because operator + is not defined for types ObjectId and String... but I get the feeling yours didn't do that (c# maybe? seems odd)

Other than that, this code worked in VB...with a different block name. I even made the block dynamic, and it still worked.

You actually don't need the graphics flush either, because the graphics will update when you close the object anyway.



Are you sure there are visible entities in your block?



You should do your Transaction and Try/Catch a little differently, but it is not causing your problem.

the way you have your try/catch and transaction, the trans will not get disposed if there is an exception.

if you do it this way, it always gets disposed. (you'll have to pardon me if I mess up on the syntax)



transaction tr = db.TransactionManager.StartTransaction();

try

{

....

tr.commit();

}

catch ex as .....

{

msg

}

finally

{

tr.dispose

}
Dave O.                                                                  Sig-Logos32.png
Message 3 of 28
joelkarr
in reply to: joelkarr

chief

thanks for your reply. I think you are right and I need to include attributes with the dynamic blocks to make sure they are visible dynamic blocks.

Also, thanks for the tips on reorganizing my code. You are definitely correct.

I also found out that I can change layer and other properties by just editing the block reference before I add it to the table with br.layer = "layername"

Thanks again
Message 4 of 28
Anonymous
in reply to: joelkarr


Bad advice, but that's understandable given your
level.

 

using( ) always disposes the object, and that's
how

it should be done.


 

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000
through 2009

href="http://www.acadxtabs.com">http://www.acadxtabs.com

 


 

 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
I
use VB, so I translated it...

This line gave me a compile error
"ed.WriteMessage(bdId + nameOfBlock + " inserted");"

because operator +
is not defined for types ObjectId and String... but I get the feeling yours
didn't do that (c# maybe? seems odd)

Other than that, this code worked
in VB...with a different block name. I even made the block dynamic, and it
still worked.

You actually don't need the graphics flush either,
because the graphics will update when you close the object
anyway.



Are you sure there are visible entities in your
block?



You should do your Transaction and Try/Catch a little
differently, but it is not causing your problem.

the way you have your
try/catch and transaction, the trans will not get disposed if there is an
exception.

if you do it this way, it always gets disposed. (you'll have
to pardon me if I mess up on the syntax)



transaction tr =
db.TransactionManager.StartTransaction();

try

{

....

tr.commit();

}

catch
ex as
.....

{

msg

}

finally

{

tr.dispose

}
Message 5 of 28
Anonymous
in reply to: joelkarr

Sorry, chief is not definitely correct.

VB programmers generally don't follow the same pattern
that well-written C# programs do.

The using() directive is the preferred way to use any
object that must be Disposed of, because it eliminates
a the confusion introduced by try/catch/finally.

{code}

using (Transaction trans = db.TransactionManager.StartTransaction())
{
// use your transaction here
trans.Commit();

} // trans is automatically disposed here

{code}

That's all you need insofar as using a transaction goes,
and it is equivalent to this more confusing code:

{code}

Transaction trans = db.TransactionManager.StartTransaction();
try
{
// use transaction here
trans.Commit();
}
finally
{
if( trans != null )
trans.Dispose();
}

{code}

Take a moment to study the two, and you should be able to
see why the first is cleaner and more easily understood than the
second.

The key to understanding using() is that the call to Dispose() is
made automatically at the closing curly brace, and once you get
used to thinking about it in those terms, you will never want to
use the more confusing try/finally approach that 'chief' thinks is
proper coding.


--

http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm


wrote in message news:6079552@discussion.autodesk.com...
chief thanks for your reply. I think you are right and I need to include attributes with the dynamic blocks to make sure they are visible dynamic blocks. Also, thanks for the tips on reorganizing my code. You are definitely correct. I also found out that I can change layer and other properties by just editing the block reference before I add it to the table with br.layer = "layername" Thanks again
Message 6 of 28
JamieVJohnson
in reply to: joelkarr

While Tony states that Using is great for wrapping up Transactions in a nice neat little package is good, his statement about "you will never want to use the more confusing try/finally approach that 'chief' thinks is proper coding." is not correct.



Try/Catch/Finally blocks are VERY helpful when attempting to capture errors that will become fatal otherwise. In fact it is best to use them ANY time the UI has a user control event. Then CATCH the error and handle it, with a Finally that wraps up anything else that Using's auto disposal is not appropriate for. Automatic disposal is not appropriate for setting a variable back to another value (such as a boolean to ignore events). Catch is also helpful for those random events such as inserting a block from file when the file was renamed/moved/deleted.



So to sum up, Using is great for items that MUST be disposed, Try/Catch/Finally is great for trapping error prone areas of code.



That will be $0.02 please.



jvj
Message 7 of 28
chiefbraincloud
in reply to: joelkarr


Inflation is really out of control!..





Normally you only get a penny for your thoughts;-)

Dave O.                                                                  Sig-Logos32.png
Message 8 of 28
Anonymous
in reply to: joelkarr


He wasn't saying not to use try/catch/finally but
not to use it to dispose of objects that implement IDisposable.

Check out the link below for an interesting
read - Tony chimed in on the treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice neat
little package is good, his statement about "you will never want to use the
more confusing try/finally approach that 'chief' thinks is proper coding." is
not correct.



Try/Catch/Finally blocks are VERY helpful when
attempting to capture errors that will become fatal otherwise. In fact it is
best to use them ANY time the UI has a user control event. Then CATCH the
error and handle it, with a Finally that wraps up anything else that Using's
auto disposal is not appropriate for. Automatic disposal is not appropriate
for setting a variable back to another value (such as a boolean to ignore
events). Catch is also helpful for those random events such as inserting a
block from file when the file was renamed/moved/deleted.



So to
sum up, Using is great for items that MUST be disposed, Try/Catch/Finally is
great for trapping error prone areas of code.



That will be
$0.02 please.



jvj
Message 9 of 28
Anonymous
in reply to: joelkarr

I think You have exception handling and termination
handling confused. They are two different things.

Using try/finally for disposing (termination handling)
is certainly more confusing than using().

That has nothing to do with exception handling.

It can become much worse when you have multiple,
dependent objects that must disposed.

In the following examples, keep in mind the fact
that the GetFirst() and GetSecond() methods may
throw an exception, which is what mandates the
need for nested try/finally blocks, rather than only
one, to properly clean up the three disposables:

{code}

IDisposable first = / ... assign
try
{
IDisposable second = first.GetSecond(); // dependent
try
{
IDisposable third = second.GetThird(); // dependent
try
{
// use first, second and third here
}
finally
{
third.Dispose();
}
}
finally
{
second.Dispose();
}
}
finally
{
first.Dispose();
}

{code}

And, in contrast to that utter nonsense:

{code}

using( IDisposable first = // assign )
using( IDisposable second = first.GetSecond() )
using( IDisposable third = second.GetThird() )
{
// use first, second, and third here
}

{code}


Would you like some hot sauce to go with that shoe?

--

http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009
http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm


wrote in message news:6080237@discussion.autodesk.com...
While Tony states that Using is great for wrapping up Transactions in a nice neat little package is good, his statement about "you will never want to use the more confusing try/finally approach that 'chief' thinks is proper coding." is not correct.



Try/Catch/Finally blocks are VERY helpful when attempting to capture errors that will become fatal otherwise. In fact it is best to use them ANY time the UI has a user control event. Then CATCH the error and handle it, with a Finally that wraps up anything else that Using's auto disposal is not appropriate for. Automatic disposal is not appropriate for setting a variable back to another value (such as a boolean to ignore events). Catch is also helpful for those random events such as inserting a block from file when the file was renamed/moved/deleted.



So to sum up, Using is great for items that MUST be disposed, Try/Catch/Finally is great for trapping error prone areas of code.



That will be $0.02 please.



jvj
Message 10 of 28
JamieVJohnson
in reply to: joelkarr


No, I like Bar-B-Que...



Anyway, You just said the same thing I did in a different manner.



Using is good for disposing whether on purpose or by accident.



Try/Catch/Finally is good for error trapping and handling.



My original point was simply not to dismiss Try/Catch/Finally as a 'useless' programming feature.



Any Questions?



jvj



p.s. serve it fried on a stick, and I'll eat anything with bbq sauce.

Message 11 of 28
Anonymous
in reply to: joelkarr


Look, if you can't admit to your own error then I can help you
with that, by just
making your error clear
and obvious:

 

{quote}

 

his statement about "you will never want to use the more
confusing try/finally approach that 'chief' thinks is proper coding." is not
correct.

{quote}

 

You are confusing your inability to understand the statement
with its correctness, and have since achieved little other than

size=2>make it obvious that you didn't understand my original statement to start
with.

 

Go back and read it again.

 

My statement you refer to above, and claim is 'not correct'
was specifically about the use of try/finally for ensuring something is
disposed.
It was NOT about using try/catch/finally for
exception handling. The only problem here, is that you aren't able to
distinguish the difference, or understand what termination handling is, and how
it differs from exception handling.

 


Next time, take a few moments to try to understand what you're
reading, and you may be fortunate enough to avoid having to make a fool of
yourself.


 

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000
through 2009

href="http://www.acadxtabs.com">http://www.acadxtabs.com

 


 

 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


No, I like Bar-B-Que...



Anyway, You
just said the same thing I did in a different manner.



Using is
good for disposing whether on purpose or by accident.




Try/Catch/Finally is good for error trapping and
handling.



My original point was simply not to dismiss
Try/Catch/Finally as a 'useless' programming feature.



Any
Questions?



jvj



p.s. serve it fried on a stick,
and I'll eat anything with bbq sauce.

Message 12 of 28
Anonymous
in reply to: joelkarr


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally but
not to use it to dispose of objects that implement IDisposable.

Check out the link below for an interesting
read - Tony chimed in on the treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice neat
little package is good, his statement about "you will never want to use the
more confusing try/finally approach that 'chief' thinks is proper coding."
is not correct.



Try/Catch/Finally blocks are VERY helpful
when attempting to capture errors that will become fatal otherwise. In fact
it is best to use them ANY time the UI has a user control event. Then CATCH
the error and handle it, with a Finally that wraps up anything else that
Using's auto disposal is not appropriate for. Automatic disposal is not
appropriate for setting a variable back to another value (such as a boolean
to ignore events). Catch is also helpful for those random events such as
inserting a block from file when the file was
renamed/moved/deleted.



So to sum up, Using is great for items
that MUST be disposed, Try/Catch/Finally is great for trapping error prone
areas of code.



That will be $0.02
please.



jvj
Message 13 of 28
Anonymous
in reply to: joelkarr


One way is to chase its type by right clicking the
type and choosing 'go to definition'. This will display the metadata for
the

type. Now check what is inherits from. Repeat the
process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the way -
nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the object
browser instead showing metadata. If so just check if the type has a
Dispose()

method.

 

The goal with using a using statement is to make
sure the unmanaged resource we are pointing to gets Disposed.

face=Arial size=2>We don't want

the object to go out of scope and possibly get
Garbaged Collected before the unmanaged memory is
released. This is a memory

leak in .net.

 

This same question came up on StackOverflow.com a
few weeks ago... Plow through here to find the answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally
but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want to
use the more confusing try/finally approach that 'chief' thinks is proper
coding." is not correct.



Try/Catch/Finally blocks are VERY
helpful when attempting to capture errors that will become fatal
otherwise. In fact it is best to use them ANY time the UI has a user
control event. Then CATCH the error and handle it, with a Finally that
wraps up anything else that Using's auto disposal is not appropriate for.
Automatic disposal is not appropriate for setting a variable back to
another value (such as a boolean to ignore events). Catch is also helpful
for those random events such as inserting a block from file when the file
was renamed/moved/deleted.



So to sum up, Using is great for
items that MUST be disposed, Try/Catch/Finally is great for trapping error
prone areas of code.



That will be $0.02
please.



jvj
Message 14 of 28
Anonymous
in reply to: joelkarr


Note that you can obviously check for a Dispose()
method in the metadata for the type and don't have to

chase for IDisposable. Just a nice way to learn
what is happening in there.

 

Tony has written about Autocad types that expose a
Dispose() method. Not sure how the search tool are

working but give it a try. Also you can just do a
brute force search on '
size=3>http://www.caddzone.com
' and

start plowing through.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


One way is to chase its type by right clicking
the type and choosing 'go to definition'. This will display the metadata for
the

type. Now check what is inherits from. Repeat the
process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the way -
nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the object
browser instead showing metadata. If so just check if the type has a
Dispose()

method.

 

The goal with using a using statement is to make
sure the unmanaged resource we are pointing to gets Disposed.

face=Arial size=2>We don't want

the object to go out of scope and possibly
get
Garbaged Collected before the unmanaged
memory is released. This is a memory

leak in .net.

 

This same question came up on StackOverflow.com a
few weeks ago... Plow through here to find the answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message

href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally
but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want to
use the more confusing try/finally approach that 'chief' thinks is
proper coding." is not correct.



Try/Catch/Finally blocks
are VERY helpful when attempting to capture errors that will become
fatal otherwise. In fact it is best to use them ANY time the UI has a
user control event. Then CATCH the error and handle it, with a Finally
that wraps up anything else that Using's auto disposal is not
appropriate for. Automatic disposal is not appropriate for setting a
variable back to another value (such as a boolean to ignore events).
Catch is also helpful for those random events such as inserting a block
from file when the file was renamed/moved/deleted.



So to
sum up, Using is great for items that MUST be disposed,
Try/Catch/Finally is great for trapping error prone areas of
code.



That will be $0.02
please.



jvj
Message 15 of 28
Anonymous
in reply to: joelkarr


I appreciate your response. I have always been
curious because of folks in here promoting the use of the "using"
keyword.

 

 

"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

One way is to chase its type by right clicking
the type and choosing 'go to definition'. This will display the metadata for
the

type. Now check what is inherits from. Repeat the
process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the way -
nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the object
browser instead showing metadata. If so just check if the type has a
Dispose()

method.

 

The goal with using a using statement is to make
sure the unmanaged resource we are pointing to gets Disposed.

face=Arial size=2>We don't want

the object to go out of scope and possibly
get
Garbaged Collected before the unmanaged
memory is released. This is a memory

leak in .net.

 

This same question came up on StackOverflow.com a
few weeks ago... Plow through here to find the answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message

href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally
but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want to
use the more confusing try/finally approach that 'chief' thinks is
proper coding." is not correct.



Try/Catch/Finally blocks
are VERY helpful when attempting to capture errors that will become
fatal otherwise. In fact it is best to use them ANY time the UI has a
user control event. Then CATCH the error and handle it, with a Finally
that wraps up anything else that Using's auto disposal is not
appropriate for. Automatic disposal is not appropriate for setting a
variable back to another value (such as a boolean to ignore events).
Catch is also helpful for those random events such as inserting a block
from file when the file was renamed/moved/deleted.



So to
sum up, Using is great for items that MUST be disposed,
Try/Catch/Finally is great for trapping error prone areas of
code.



That will be $0.02
please.



jvj
Message 16 of 28
Anonymous
in reply to: joelkarr


Your welcome... A nice key-binding to get you back
to where you started when using 'go to definition' is
'ctrl+shift+f12'.

This will bring you back to where you started no
matter how deep you chase the type with 'go to definition'.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


I appreciate your response. I have always been
curious because of folks in here promoting the use of the "using"
keyword.

 

 

"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

One way is to chase its type by right clicking
the type and choosing 'go to definition'. This will display the metadata for
the

type. Now check what is inherits from. Repeat
the process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the way
- nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the
object browser instead showing metadata. If so just check if the type has a
Dispose()

method.

 

The goal with using a using statement is to
make sure the unmanaged resource we are pointing to gets Disposed.
We don't want

the object to go out of scope and possibly
get
Garbaged Collected before the unmanaged
memory is released. This is a memory

leak in .net.

 

This same question came up on StackOverflow.com
a few weeks ago... Plow through here to find the answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object
implements IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message

href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use
try/catch/finally but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want
to use the more confusing try/finally approach that 'chief' thinks is
proper coding." is not correct.



Try/Catch/Finally
blocks are VERY helpful when attempting to capture errors that will
become fatal otherwise. In fact it is best to use them ANY time the UI
has a user control event. Then CATCH the error and handle it, with a
Finally that wraps up anything else that Using's auto disposal is not
appropriate for. Automatic disposal is not appropriate for setting a
variable back to another value (such as a boolean to ignore events).
Catch is also helpful for those random events such as inserting a
block from file when the file was
renamed/moved/deleted.



So to sum up, Using is great for
items that MUST be disposed, Try/Catch/Finally is great for trapping
error prone areas of code.



That will be $0.02
please.



jvj
Message 17 of 28
Anonymous
in reply to: joelkarr


>>Your welcome..

Opposite of 'My welcome...' ~)


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080610@discussion.autodesk.com">news:6080610@discussion.autodesk.com
...


Your welcome... A nice key-binding to get you
back to where you started when using 'go to definition' is
'ctrl+shift+f12'.

This will bring you back to where you started no
matter how deep you chase the type with 'go to definition'.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


I appreciate your response. I have always been
curious because of folks in here promoting the use of the "using"
keyword.

 

 

"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

One way is to chase its type by right
clicking the type and choosing 'go to definition'. This will display the
metadata for the

type. Now check what is inherits from. Repeat
the process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the
way - nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the
object browser instead showing metadata. If so just check if the type has
a Dispose()

method.

 

The goal with using a using statement is to
make sure the unmanaged resource we are pointing to gets Disposed.
We don't want

the object to go out of scope and
possibly get
Garbaged Collected before the
unmanaged memory is released. This is a memory

leak in .net.

 

This same question came up on
StackOverflow.com a few weeks ago... Plow through here to find the
answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object
implements IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in
message
href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use
try/catch/finally but not to use it to dispose of objects that
implement IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a
nice neat little package is good, his statement about "you will
never want to use the more confusing try/finally approach that
'chief' thinks is proper coding." is not
correct.



Try/Catch/Finally blocks are VERY helpful
when attempting to capture errors that will become fatal otherwise.
In fact it is best to use them ANY time the UI has a user control
event. Then CATCH the error and handle it, with a Finally that wraps
up anything else that Using's auto disposal is not appropriate for.
Automatic disposal is not appropriate for setting a variable back to
another value (such as a boolean to ignore events). Catch is also
helpful for those random events such as inserting a block from file
when the file was renamed/moved/deleted.



So to sum
up, Using is great for items that MUST be disposed,
Try/Catch/Finally is great for trapping error prone areas of
code.



That will be $0.02
please.



jvj
Message 18 of 28
Anonymous
in reply to: joelkarr


You might also want to write a Transaction both
ways and look at the IL. You'll see they both end up

as a try/finally. You can use ildasm.exe to load
the assembly and look at the IL.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080610@discussion.autodesk.com">news:6080610@discussion.autodesk.com
...


Your welcome... A nice key-binding to get you
back to where you started when using 'go to definition' is
'ctrl+shift+f12'.

This will bring you back to where you started no
matter how deep you chase the type with 'go to definition'.


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


I appreciate your response. I have always been
curious because of folks in here promoting the use of the "using"
keyword.

 

 

"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

One way is to chase its type by right
clicking the type and choosing 'go to definition'. This will display the
metadata for the

type. Now check what is inherits from. Repeat
the process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the
way - nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the
object browser instead showing metadata. If so just check if the type has
a Dispose()

method.

 

The goal with using a using statement is to
make sure the unmanaged resource we are pointing to gets Disposed.
We don't want

the object to go out of scope and
possibly get
Garbaged Collected before the
unmanaged memory is released. This is a memory

leak in .net.

 

This same question came up on
StackOverflow.com a few weeks ago... Plow through here to find the
answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object
implements IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in
message
href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use
try/catch/finally but not to use it to dispose of objects that
implement IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a
nice neat little package is good, his statement about "you will
never want to use the more confusing try/finally approach that
'chief' thinks is proper coding." is not
correct.



Try/Catch/Finally blocks are VERY helpful
when attempting to capture errors that will become fatal otherwise.
In fact it is best to use them ANY time the UI has a user control
event. Then CATCH the error and handle it, with a Finally that wraps
up anything else that Using's auto disposal is not appropriate for.
Automatic disposal is not appropriate for setting a variable back to
another value (such as a boolean to ignore events). Catch is also
helpful for those random events such as inserting a block from file
when the file was renamed/moved/deleted.



So to sum
up, Using is great for items that MUST be disposed,
Try/Catch/Finally is great for trapping error prone areas of
code.



That will be $0.02
please.



jvj
Message 19 of 28
Anonymous
in reply to: joelkarr


For the purpose of using(), the compiler will not allow you
to

use it with an object that doesn't implement
IDisposable.

 

More generally, you query an object to see if it
supports

a given interface, in one of two basic ways, depending
on

what you are going to do if it does.

 

If you just want to know if an object supports an
interface,

(IDisposable in this example) then you just do
this:

 

{code}

 

    object someObject = // assign

 

    if( someObject is IDisposable
)

    {

        // yes it
is

    }

 

{code}

 

If you are going to use the interface methods of the
object

(which requires you to cast the object to the interface
type)

this is the preferred way:

 

{code}

 

   object someObject = // assign

 

   IDisposable disposable = someObject as
IDisposable;

   if( disposable != null )

   {

       // yes it is, and use
disposable's methods here

   }

 

{code}


size=2>
 

The reason why the second method is prefered when you
are

going to use the interface methods, is because you can
avoid

the redundance of using both the 'is' and 'as' operators,
which

essentially the same thing, except that 'is' returns true,
while

'as' returns the object on the left, cast to type on the
right.


 

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000
through 2009

href="http://www.acadxtabs.com">http://www.acadxtabs.com

 


 

 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally
but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want to
use the more confusing try/finally approach that 'chief' thinks is proper
coding." is not correct.



Try/Catch/Finally blocks are VERY
helpful when attempting to capture errors that will become fatal
otherwise. In fact it is best to use them ANY time the UI has a user
control event. Then CATCH the error and handle it, with a Finally that
wraps up anything else that Using's auto disposal is not appropriate for.
Automatic disposal is not appropriate for setting a variable back to
another value (such as a boolean to ignore events). Catch is also helpful
for those random events such as inserting a block from file when the file
was renamed/moved/deleted.



So to sum up, Using is great for
items that MUST be disposed, Try/Catch/Finally is great for trapping error
prone areas of code.



That will be $0.02
please.



jvj
Message 20 of 28
Anonymous
in reply to: joelkarr



>>I think 'go to definition' in 05 opens the
object browser instead showing metadata. If so just check if the type has a
Dispose()

>>method.

 

btw... In vs2005 F12( 'go to definition' ) also takes you to the
metadata for the type. It's R# that redefines F12 to point to the

object browser. Whoever did this should have his compiler taken
away!


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message
href="news:6080571@discussion.autodesk.com">news:6080571@discussion.autodesk.com
...


One way is to chase its type by right clicking
the type and choosing 'go to definition'. This will display the metadata for
the

type. Now check what is inherits from. Repeat the
process for the types in inherits from until you come to an end or
find

IDisposable. Open all comments up along the way -
nice way to see what is going in there...

 

I think 'go to definition' in 05 opens the object
browser instead showing metadata. If so just check if the type has a
Dispose()

method.

 

The goal with using a using statement is to make
sure the unmanaged resource we are pointing to gets Disposed.

face=Arial size=2>We don't want

the object to go out of scope and possibly
get
Garbaged Collected before the unmanaged
memory is released. This is a memory

leak in .net.

 

This same question came up on StackOverflow.com a
few weeks ago... Plow through here to find the answer.


 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">


How does one know whether an object implements
IDisposable?


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
"Paul Richardson" <prichardson<lastpoint> wrote in message

href="news:6080266@discussion.autodesk.com">news:6080266@discussion.autodesk.com
...


He wasn't saying not to use try/catch/finally
but not to use it to dispose of objects that implement
IDisposable.

Check out the link below for an
interesting read - Tony chimed in on the
treads.

 



style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
While
Tony states that Using is great for wrapping up Transactions in a nice
neat little package is good, his statement about "you will never want to
use the more confusing try/finally approach that 'chief' thinks is
proper coding." is not correct.



Try/Catch/Finally blocks
are VERY helpful when attempting to capture errors that will become
fatal otherwise. In fact it is best to use them ANY time the UI has a
user control event. Then CATCH the error and handle it, with a Finally
that wraps up anything else that Using's auto disposal is not
appropriate for. Automatic disposal is not appropriate for setting a
variable back to another value (such as a boolean to ignore events).
Catch is also helpful for those random events such as inserting a block
from file when the file was renamed/moved/deleted.



So to
sum up, Using is great for items that MUST be disposed,
Try/Catch/Finally is great for trapping error prone areas of
code.



That will be $0.02
please.



jvj

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk DevCon in Munich May 28-29th


Autodesk Design & Make Report

”Boost