HandleToObject Problem
Paulo Martins
Hi,
I'm developing a database application with Autocad 14.0. I did choose to
link my database
objects with Autocad entities through the entity handle.
To verify consistency of my database, I need to verify if the entities
associated with
database still exist in the drawing. To do so I made a function that calls
the
"HandleToObject" for each handle that I have in database. After some
iterations
an exception occurs. Other times AutoCAD can't recognize some methods that I
call,
returning a message like this: " method not supported "
Can anybody help me with this problem?
I'm using Delphi 3.0 to develop my application, but I tried with VBA and I
had the same problem that can be noted with this sample:
----------------------------------------------------------------------------
-----------------------------------------
Private Sub FindEntities()
Dim i As Integer
Dim e As Object
Dim strHandle
Dim n As Integer
n = 0
For i = 1 To 1000
strHandle = Hex(i)
' After some iterations an exception will be thrown in the line below
Set e = ThisDrawing.HandleToObject(strHandle)
If (Not IsNull(e)) Then
n = n + 1
End If
Next i
MsgBox ("Found " + Str(n) + " objects")
End Sub
----------------------------------------------------------------------------
-----------------------------------------
Any comments will be appreciated
Paulo Martins
pau...@SPAMcpfl.com.br
Please, remove the word SPAM to reply
Jon Fleming
I don't know.
Note that the handle is only guaranteed unique within one drawing. If your
database application is going to handle more than one drawing, you need
further information to uniquely specify an entity. Candidates are the drawing
file name, some unique text in a title block, or anything that is different in
all your drawings.
jrf
Tony Tanzillo
I haven't used HandleToObject so I can't tell you what
might be the problem. It's possible that AutoCAD will
throw an exception if there's no object in the database
with the specified handle.
The reason you're probably getting 'method not supported'
for some objects, is because every object in a drawing has
a handle, but not all of them are entities (for example,
layers and other table and dictionary objects have handles).
It's also possible that HandleToObject does not return
table and dictionary objects, and throws an exception
instead.
A flaw in the Automation interface is that there is no
common method that can be called to indentify what type
of object you're dealing with. The only way to do it,
is to repeatedly try to downcast the object to one of
several different child interfaces (IAcadLayer, or
IAcadCircle for example), and if in doing so, you don't
get an 'interface not supported' exception, then you've
determined the type of object.
For example:
Function IsAcadLayer(anObj: OleVariant): Boolean;
begin
try
IDispatch(anObj) as IAcadLayer;
except
Result := False;
exit;
end;
Result := True;
end;
If you want to determine if an object is an entity
(with the exception of MINES and custom objects),
then you might do this:
Function IsAcadEntity(anObj: OleVariant): Boolean;
begin
try
anObj.EntityType; // only supported by entities
except
Result := False;
exit
end;
Result := True;
end;
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6h5p8n$q6...@adesknews2.autodesk.com>...
Antonio Barroca
Your function hangs becaus you give an handle that doesn't existe in the
drawing database.
You create the handle using the Hex() of a number between 1 and 1000.
Is not mandatory that all the objects in the database have an handle
that start with the Hex(1) by step of 1.
The way that AutoCad calculate the handle is more complex than this.
You should mybe in your database store the handle of the objects, and
use this handle to verify if the objects still exist in the drawing.
Best Regards
Paulo Martins wrote:
> Hi,
>
> I'm developing a database application with Autocad 14.0. I did choose
> to
> link my database
> objects with Autocad entities through the entity handle.
>
> To verify consistency of my database, I need to verify if the entities
>
> associated with
> database still exist in the drawing. To do so I made a function that
> calls
> the
> "HandleToObject" for each handle that I have in database. After some
> iterations
> an exception occurs. Other times AutoCAD can't recognize some methods
> that I
> call,
> returning a message like this: " method not supported "
>
> Can anybody help me with this problem?
>
> I'm using Delphi 3.0 to develop my application, but I tried with VBA
> and I
> had the same problem that can be noted with this sample:
> --------------------------------------------------------
> -------------------
> -----------------------------------------
> Private Sub FindEntities()
> Dim i As Integer
> Dim e As Object
> Dim strHandle
> Dim n As Integer
> n = 0
> For i = 1 To 1000
> strHandle = Hex(i)
> ' After some iterations an exception will be thrown in the line
> below
> Set e = ThisDrawing.HandleToObject(strHandle)
> If (Not IsNull(e)) Then
> n = n + 1
> End If
> Next i
> MsgBox ("Found " + Str(n) + " objects")
> End Sub
> -------
> --------------------------------------------------------------------
Paulo Martins
Hi Antonio
Antonio Barroca wrote in message <35374827...@autodesk.com>...
>Paulo
>
>Your function hangs becaus you give an handle that doesn't existe in the
>drawing database.
>You create the handle using the Hex() of a number between 1 and 1000.
>Is not mandatory that all the objects in the database have an handle
>that start with the Hex(1) by step of 1.
>The way that AutoCad calculate the handle is more complex than this.
>
>You should mybe in your database store the handle of the objects, and
>use this handle to verify if the objects still exist in the drawing.
>
This is what I'm trying to do.
You said that the HandleToObject function hangs because I gave a handle
that didn't exist. So, how can I locate for an entity without using the
HandleToObject function ?
The main problem is that after using the HandleToObject the Autocad
appears to be corrupted. Sometimes I get a FATAL ERROR that
exits the AutoCAD.
Let me explain better:
My application allows that the user make links between entities
of the drawing and rows of a table (using the handle).
Suppose that between two sessions the user delete some entities
of the drawing that was linked with the database. Due to keep the
integrity of the database I made a function that checks if the entities
that was linked with the database still exists in the drawing.
So I always will locate for handles of entities that still exist or had
existed in the drawing.
After calling HandleToObject sometimes I think that AutoCAD becomes
corrupted. When I try to exit AutoCAD I get the message:
FATAL ERROR: Unhandled Access Violation Exception at xxxxxxh
My main purpose is to check if an entity that were in a drawing
still remains there. If you have a suggestion to solve this
problem I will be very grateful.
Paulo Martins
Hi Tony,
Tony Tanzillo wrote in message <6h6l6f$rg...@adesknews2.autodesk.com>...
>I haven't used HandleToObject so I can't tell you what
>might be the problem. It's possible that AutoCAD will
>throw an exception if there's no object in the database
>with the specified handle.
If AutoCAD throw an exception when it does not find the
object what I can use to verify if a object was deleted ?
Have you any suggestion ?
>
>The reason you're probably getting 'method not supported'
>for some objects, is because every object in a drawing has
>a handle, but not all of them are entities (for example,
>layers and other table and dictionary objects have handles).
>
>It's also possible that HandleToObject does not return
>table and dictionary objects, and throws an exception
>instead.
>
Let me explain better:
My application allows that the user makes links between entities
of the drawing and rows of a table.
Suppose that between two sessions the user delete some entities
of the drawing that was linked with the database. Due to keep the
integrity of the database I made a function that checks if the entities
that was linked with the database still exists in the drawing.
So I always will locate for handles of entities that still exist or had
existed
in the drawing.
After calling HandleToObject sometimes I think that AutoCAD becomes
corrupted. When I try to exit AutoCAD I get the message:
FATAL ERROR: Unhandled Access Violation Exception at xxxxxxh
My main purpose is to check if an entity that were in a drawing
still remains there. If you have a suggestion to solve this
problem I will be very grateful.
Paulo Martins
Hi Jon,
Jon Fleming wrote in message ...
>I don't know.
>
>Note that the handle is only guaranteed unique within one drawing. If your
>database application is going to handle more than one drawing, you need
>further information to uniquely specify an entity. Candidates are the
drawing
>file name, some unique text in a title block, or anything that is different
in
>all your drawings.
>
>jrf
I knew that and I put the drawing name in the database.
Thanks anyway!
Tony Tanzillo
Paulo - You can still use the HandleToObject() method to
test whether an object with a given handle exists in the
drawing. You just have to handle the exception.
This Delphi function will return an object given its
handle, or a NULL variant if no object in the drawing
has the specified handle:
Function ObjectFromHandle(doc : OleVariant; Handle: String): OleVariant;
begin
try
Result := doc.HandleToObject(handle);
except
On E: EOleException do
begin
if E.Message = 'Invalid Handle' then // No object with
Result := NULL // this handle
else
Raise; // Something else is wrong,
end // so re-raise the exception
end;
end;
This code below uses a form with a TButton and a
TEdit on it, into which you can enter an entity
handle.
When you click the button, if there's an entity
in the drawing with a handle equal to the string
in the edit box, the entity is highlighted, else
a message box appears saying there's no object in
the drawing with the specified handle:
Procedure TForm1.Button1Click(Sender: TObject);
var
AnObject, Acad, Doc : OleVariant;
begin
If Edit1.Text <> '' then
begin
Acad := GetActiveOleObject('AutoCAD.Application');
Doc := Acad.ActiveDocument;
AnObject := ObjectFromHandle(Doc, Edit1.Text);
If VarIsNull(AnObject) then
ShowMessage('No object with that handle')
else
AnObject.Highlight(True);
end;
end;
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6h854s$rg...@adesknews2.autodesk.com>...
Tony Tanzillo
Paulo - I need to know what revision of AutoCAD this
is. At the command prompt, enter "_VERNUM", and tell
me what it says.
There is an additional problem that you might be
having in your test code, that would probably not
happen in most real-world applications.
When you call HandleToObject(), and pass it the
entity handle of a table object (like the layer
table, which usually has a value in the range of
1-12), AutoCAD does not throw an exception (which
it probably should). Instead, it returns a NULL
pointer to an IDispatch interface.
That's a bug.
This version of ObjectFromHandle() catches it:
Function ObjectFromHandle(doc : OleVariant; Handle: String): OleVariant;
begin
try
Result := doc.HandleToObject(handle);
If (VarType(result) <> varDispatch) or
(TVarData(v).VDispatch = nil) then
Result := NULL;
except
on e: Exception do
if e.Message <> 'Invalid Handle' then
Raise;
end;
end;
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6hb0sn$so...@adesknews2.autodesk.com>...
>Hi Tony,
>
>I already had a function like yours "ObjectFromHandle" but my main
>problem is that AutoCAD hangs after using that function.
>
>I'm attaching to this message a little Delphi 3 project.
>Please try it. I always get a FATAL ERROR in AutoCAD after
>running it.
>
>First the program inserts a circle and a text using "AddCircle /AddText".
>After this, it looks for handles in the 1..100 range and finally
>it inserts a Circle and a Text again.
>
>If you run this project 2 times, on the second time you will get an
>exception
>from AutoCAD and if you try to exit AutoCAD you will get a FATAL ERROR.
>
>------------------------------------------------------------
>Paulo Martins
>email: pau...@SPAMcpfl.com.br
>Please remove the SPAM word above before reply.
>
>
>--
>
>Tony Tanzillo wrote in message <6h8fvj$rf...@adesknews2.autodesk.com>...
Tony Tanzillo
Paulo - I looked at your code, and it also happens on
R14.01. I added the modified version of HandleFromObject()
and it still happens. I also eliminated the creation of
any new objects in the drawing, and it still happens.
In general, I'd say that trying to access objects with
handles in that range (which are typically tables and
other things that are exposed as collection objects),
you are asking for trouble.
In a real application, there is no need to access every
object starting at handle value 0x1. You should probably
get the handle of the first object in the model space
collection, and avoid accessing handles with values less
than that.
Note that the HandleToObject() that I posted earlier
is bugged. This one works:
Function ObjectFromHandle(doc : OleVariant; Handle: String): OleVariant;
begin
try
Result := doc.HandleToObject(handle);
If (VarType(result) <> varDispatch) or
(TVarData(result).VDispatch = nil) then
Result := NULL;
except
on e: Exception do
if e.Message <> 'Invalid Handle' then
Raise;
end;
end;
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6hb0sn$so...@adesknews2.autodesk.com>...
>Hi Tony,
>
>I already had a function like yours "ObjectFromHandle" but my main
>problem is that AutoCAD hangs after using that function.
>
>I'm attaching to this message a little Delphi 3 project.
>Please try it. I always get a FATAL ERROR in AutoCAD after
>running it.
>
>First the program inserts a circle and a text using "AddCircle /AddText".
>After this, it looks for handles in the 1..100 range and finally
>it inserts a Circle and a Text again.
>
>If you run this project 2 times, on the second time you will get an
>exception
>from AutoCAD and if you try to exit AutoCAD you will get a FATAL ERROR.
>
>------------------------------------------------------------
>Paulo Martins
>email: pau...@SPAMcpfl.com.br
>Please remove the SPAM word above before reply.
>
>
>--
>
>Tony Tanzillo wrote in message <6h8fvj$rf...@adesknews2.autodesk.com>...
Jon Fleming
I hope that the code he posted is just a test program, and the real code
only looks for objects that used to exist and may still exist, using the
handle that the object had last time he looked. In other words:
For all records in the database that pertain to this drawing
Extract the next previously-valid handle number from the database.
If no object exists with that handle:
Take some action (tell the user or remove the associated record or ...)
End loop
If a program using that algorithm blows up, there's some other problem here
...
jrf
In article <6hbq53$sn...@adesknews2.autodesk.com>, Tony Tanzillo wrote:
> Paulo - I looked at your code, and it also happens on
> R14.01. I added the modified version of HandleFromObject()
> and it still happens. I also eliminated the creation of
> any new objects in the drawing, and it still happens.
>
> In general, I'd say that trying to access objects with
> handles in that range (which are typically tables and
> other things that are exposed as collection objects),
> you are asking for trouble.
>
> In a real application, there is no need to access every
> object starting at handle value 0x1. You should probably
> get the handle of the first object in the model space
> collection, and avoid accessing handles with values less
> than that.
>
> Note that the HandleToObject() that I posted earlier
> is bugged. This one works:
>
> Function ObjectFromHandle(doc : OleVariant; Handle: String): OleVariant;
> begin
> try
> Result := doc.HandleToObject(handle);
> If (VarType(result) <> varDispatch) or
> (TVarData(result).VDispatch = nil) then
> Result := NULL;
> except
> on e: Exception do
> if e.Message <> 'Invalid Handle' then
> Raise;
Tony Tanzillo
The HandleToObject() method is just a functional wrapper
for the RXADS handent() function. There is no checking
done to see if the value passed in the handle parameter
is higher than the handle of the most-recently created
object.
When you call it to get an object with a given handle,
and the object doesn't exist, AutoCAD throws an exception
with the message 'Invalid Handle'
But, it does something else when you pass the handle of
an object like the layer table, linetype table, and so
on. In those cases there's no error, it just returns a
NULL IDispatch pointer (which Delphi doesn't complain
about, whether it should is debatable). The only reason
one might want to get at table objects (not the objects
in a table, but the tables themselves), is to access
XDATA that might be attached to them.
There's definitely a bug in AutoCAD or the Automation
extensions that crashes ACAD when you exit after using
Paulo's program two or more times.
As I said, I think he's asking for trouble by trying to
get objects with handles in the range of 0-100 anyway.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Jon Fleming wrote in message ...
>I hope that the code he posted is just a test program, and the real code
>only looks for objects that used to exist and may still exist, using the
>handle that the object had last time he looked. In other words:
>
>For all records in the database that pertain to this drawing
> Extract the next previously-valid handle number from the database.
> If no object exists with that handle:
> Take some action (tell the user or remove the associated record or ...)
>End loop
>
>If a program using that algorithm blows up, there's some other problem here
>..
>
>jrf
>
>In article <6hbq53$sn...@adesknews2.autodesk.com>, Tony Tanzillo wrote:
>> Paulo - I looked at your code, and it also happens on
>> R14.01. I added the modified version of HandleFromObject()
>> and it still happens. I also eliminated the creation of
>> any new objects in the drawing, and it still happens.
>>
>> In general, I'd say that trying to access objects with
>> handles in that range (which are typically tables and
>> other things that are exposed as collection objects),
>> you are asking for trouble.
>>
>> In a real application, there is no need to access every
>> object starting at handle value 0x1. You should probably
>> get the handle of the first object in the model space
>> collection, and avoid accessing handles with values less
>> than that.
>>
>> Note that the HandleToObject() that I posted earlier
>> is bugged. This one works:
>>
>> Function ObjectFromHandle(doc : OleVariant; Handle: String): OleVariant;
>> begin
>> try
>> Result := doc.HandleToObject(handle);
>> If (VarType(result) <> varDispatch) or
>> (TVarData(result).VDispatch = nil) then
>> Result := NULL;
>> except
>> on e: Exception do
>> if e.Message <> 'Invalid Handle' then
>> Raise;
Paulo Martins
Hi Jon,
Jon Fleming wrote in message ...
>I hope that the code he posted is just a test program, and the real code
>only looks for objects that used to exist and may still exist, using the
>handle that the object had last time he looked. In other words:
>
>For all records in the database that pertain to this drawing
> Extract the next previously-valid handle number from the database.
> If no object exists with that handle:
> Take some action (tell the user or remove the associated record or ...)
>End loop
>
>If a program using that algorithm blows up, there's some other problem here
>..
>
>jrf
>
Yes, you got it. This is exactly the problem that I'm trying to handle with.
What I could do to avoid this problem ?
--
##################################################
# Paulo Martins
#-------------------------------------------------
# email: pau...@SPAMcorreionet.com.br
# ICQ - http://wwp.mirabilis.com/405933
# Remove the word "SPAM" above before reply.
##################################################
Paulo Martins
Hi Tony,
Tony Tanzillo wrote in message <6hd15n$sn...@adesknews2.autodesk.com>...
>...
>
>There's definitely a bug in AutoCAD or the Automation
>extensions that crashes ACAD when you exit after using
>Paulo's program two or more times.
>
>As I said, I think he's asking for trouble by trying to
>get objects with handles in the range of 0-100 anyway.
>
No, I think that you had missed what I had said on thread
<6h854s$rg...@adesknews2.autodesk.com>. Look at the excerpt below.
My program is only a test to show you how is the problem.
It would be very laborious to develop a test program that is
like my real situation, but, how I had explained before, I always look for
handles of entities that still exists in the drawing or had existed some
day, thus it will be always handles in the entities range (circles, texts,
polylines, etc).
Despite using handles in 1-100 range, this test program
simulates exactly what I had experienced on my real-world program.
Anyway, if you has some suggestion to help me I would be very grateful.
By the way, the AutoCAD version number is: S.0.79.0 (R.14.0.0).
excerpt from <6h854s$rg...@adesknews2.autodesk.com> thread:
>>>
>>> Let me explain better:
>>>
>>> My application allows that the user makes links between entities
>>> of the drawing and rows of a table.
>>>
>>> Suppose that between two sessions the user delete some entities
>>> of the drawing that was linked with the database. Due to keep the
>>> integrity of the database I made a function that checks if the entities
>>> that was linked with the database still exists in the drawing.
>>>
>>> So I always will locate for handles of entities that still exist or had
>>> existed in the drawing.
>>>
>>> After calling HandleToObject sometimes I think that AutoCAD becomes
>>> corrupted. When I try to exit AutoCAD I get the message:
>>> FATAL ERROR: Unhandled Access Violation Exception at xxxxxxh
>>> My main purpose is to check if an entity that were in a drawing
>>> still remains there. If you have a suggestion to solve this
>>> problem I will be very grateful.
Tony Tanzillo
Paulo - I modified your program to make it easier to
experiement with. The .zip file is posted in the
Customer files newsgroup, under the subject ACADOLE2.ZIP
What I have found is that the crash does not happen
if you avoid passing HandleToObject() handles that
are < 0x14.
Try running the enclosed .EXE and set the starting
value to 20 (0x14), and note that you can run it
as many times as you want, and it will not crash
AutoCAD when you exit it.
If you set the starting value to 1, then it will
run all the way through the first time, and the
second time, AutoCAD will throw an exception on
the 15th iteration.
I think your problem is solved by just avoiding
handles that are less than 0x14.
See the customerfiles newsgroup for the .ZIP file.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6hdsgr$so...@adesknews2.autodesk.com>...
>Hi Tony,
>
>Tony Tanzillo wrote in message <6hd15n$sn...@adesknews2.autodesk.com>...
>>...
>>
>>There's definitely a bug in AutoCAD or the Automation
>>extensions that crashes ACAD when you exit after using
>>Paulo's program two or more times.
>>
>>As I said, I think he's asking for trouble by trying to
>>get objects with handles in the range of 0-100 anyway.
>>
>
>No, I think that you had missed what I had said on thread
><6h854s$rg...@adesknews2.autodesk.com>. Look at the excerpt below.
>
>My program is only a test to show you how is the problem.
>It would be very laborious to develop a test program that is
>like my real situation, but, how I had explained before, I always look for
>handles of entities that still exists in the drawing or had existed some
>day, thus it will be always handles in the entities range (circles, texts,
>polylines, etc).
>
>Despite using handles in 1-100 range, this test program
>simulates exactly what I had experienced on my real-world program.
>
>Anyway, if you has some suggestion to help me I would be very grateful.
>
>By the way, the AutoCAD version number is: S.0.79.0 (R.14.0.0).
>
>excerpt from <6h854s$rg...@adesknews2.autodesk.com> thread:
>>>>
>>>> Let me explain better:
>>>>
>>>> My application allows that the user makes links between entities
>>>> of the drawing and rows of a table.
>>>>
>>>> Suppose that between two sessions the user delete some entities
>>>> of the drawing that was linked with the database. Due to keep the
>>>> integrity of the database I made a function that checks if the entities
>>>> that was linked with the database still exists in the drawing.
>>>>
>>>> So I always will locate for handles of entities that still exist or had
>>>> existed in the drawing.
>>>>
>>>> After calling HandleToObject sometimes I think that AutoCAD becomes
>>>> corrupted. When I try to exit AutoCAD I get the message:
>>>> FATAL ERROR: Unhandled Access Violation Exception at xxxxxxh
>>>> My main purpose is to check if an entity that were in a drawing
>>>> still remains there. If you have a suggestion to solve this
>>>> problem I will be very grateful.
Albert Szilvasy
Hi Paulo,
I've looked into this problem and there's to be bug that will cause this
macro to fail the second time you run it. The bug is in the Automation
interface so the usual workaround applies here:
- Create an arx app and export either and Automation object or just a
function (for inpoc clients) that wraps the AcDbDatabase::getAcDbObjectId
function and use this object/function in your delphi app.
I logged the bug in our tracking system so I hope this will be gone in the
next release.
I'm sorry,
Albert
Paulo Martins wrote in message <6h5p8n$q6...@adesknews2.autodesk.com>...
>Hi,
>
>I'm developing a database application with Autocad 14.0. I did choose to
>link my database
>objects with Autocad entities through the entity handle.
>
>To verify consistency of my database, I need to verify if the entities
>associated with
>database still exist in the drawing. To do so I made a function that calls
Paulo Martins
Hi Albert,
Albert Szilvasy wrote in message <6hek4r$sn...@adesknews2.autodesk.com>...
>Hi Paulo,
>
>I've looked into this problem and there's to be bug that will cause this
>macro to fail the second time you run it. The bug is in the Automation
>interface so the usual workaround applies here:
>- Create an arx app and export either and Automation object or just a
>function (for inpoc clients) that wraps the AcDbDatabase::getAcDbObjectId
>function and use this object/function in your delphi app.
>
I'm familiarized with Visual C++, but I know just a little about ARX.
Could you send me some directions or some example on how to
export Automation Objects from an ARX Application?
I know nothing about "inpoc clients". In fact, I never heard about it.
Could you explain me what is it about ?
>
> I logged the bug in our tracking system so I hope this will be gone in the
> next release.
>
Thanks!
Jorge Lopez
Tony,
Not all objects have COM wrappers. However, when a request for an object is
made and no wrapper object is registered for it. We will create either an
AcadObject or AcadEntity object depending on what it is derived from. No
exception should be thrown. In fact, all error reporting is done via
ISupportErrorInfo (atleast the code I have seen so far).
The only functionality available for those objects are the generic
AcadObject/AcadEntity properties/methods.
However, like you mentioned the only way to identify an object type is via
the Name/EntityName property or the EntityType type property on entities.
This is less than desireable and we are looking at correcting this issue. We
want run type identification via QueryInterface and also allow early binding
by providing AcadEntity and AcadObject interfaces on all the appropriate
objects.
Cheers,
Jorge Lopez
ActiveX/COM Development
Autodesk
Tony Tanzillo wrote in message <6h6l6f$rg...@adesknews2.autodesk.com>...
>I haven't used HandleToObject so I can't tell you what
>might be the problem. It's possible that AutoCAD will
>throw an exception if there's no object in the database
>with the specified handle.
>
>The reason you're probably getting 'method not supported'
>for some objects, is because every object in a drawing has
>a handle, but not all of them are entities (for example,
>layers and other table and dictionary objects have handles).
>
>It's also possible that HandleToObject does not return
>table and dictionary objects, and throws an exception
>instead.
>
>--
>/*********************************************************/
>/* Tony Tanzillo Design Automation Consulting */
>/* Programming & Customization for AutoCAD & Compatibles */
>/* ----------------------------------------------------- */
>/* Member of the OpenDWG Alliance */
>/* Co-Author of Maximizing AutoCAD R13 and */
>/* Maximizing AutoLISP for AutoCAD R13/R14 */
>/* ----------------------------------------------------- */
>/* tony.t...@worldnet.att.net */
>/* http://ourworld.compuserve.com/homepages/tonyt */
>/*********************************************************/
Tony Tanzillo
Jorge - Thanks for the comments. See below.
> Not all objects have COM wrappers. However, when a request for an
> object is made and no wrapper object is registered for it. We will
> create either an AcadObject or AcadEntity object depending on what
> it is derived from. No exception should be thrown.
In the case of HandleToObject(), if I pass the handle of the
layer table, or the block record table, and so on (typically
these objects have handles < 0x10), you are returning a null
interface pointer, not an IAcadObject (actually, these objects
correspond to collections like Layers and Blocks).
>However, like you mentioned the only way to identify an object type is
> via the Name/EntityName property or the EntityType type property on
> entities. This is less than desireable and we are looking at correcting
> this issue. We want run type identification via QueryInterface and also
> allow early binding by providing AcadEntity and AcadObject interfaces on
> all the appropriate objects.
I can use something like this to find out if an
object supports a given interface, but it is still
very ineffecient:
Function IsA(IID: TGUID; Obj: OleVariant): boolean;
var
pOut : Pointer;
begin
pOut := Nil;
IDispatch(Obj).QueryInterface(IID, pOut);
Result := pOut <> nil;
end;
Which I might use like this:
var
OleVariant: Acad, Util, Ent, PickPt;
begin
Acad := GetActiveOleObject('AutoCAD.Application');
Util := Acad.ActiveDocument.Utility;
Util.GetEntity(Ent, PickPt, 'Pick A CIRCLE: ');
// Loop until selected object is a circle:
While Not IsA(IAcadCircle, Ent) do
begin
ShowMessage(' Selected Object is not a circle ');
Util.GetEntity(Ent, PickPt, 'Pick a CIRCLE: ');
end
Obviously, I could just as easily use the EntityName
or EntityType properties for objects returned by the
GetEntity() method, but the case of HandleToObject(),
it could return objects that do not support EntityName
or EntityType (like a Layer or Block Object).
I would much prefer to see a method supported by every
interface which simply answers the question "what kind
of object are you?".
Albert Szilvasy
Well, exposing objects through Automation is not a very simple matter but
MFC or ATL can simplify it for you considerably.
Since in this case you just want to expose a plain Automation object as
opposed to exposing an Automation for a db object, there's nothing special
about it. I think the best way to start is to read up on the subject in the
MSVC online docs. Nevertheless, I will try to put together a sample for you
in the next few days.
I'm sorry that I use terms that are not really standard. "in-proc client" is
just a shorthand for "in-process client". It means that the client runs the
same process as the server. In you case, it means that you create a dll in
delphi that you load onto AutoCAD. I believe it is doable in delphi (it is
certainly possible in VB). I saw some messages in this newsgroup from some
of the delphi masters that led me believe that it was possible.
In case of inproc client exposing a simple function is enough. In case of
out of process client it is less than sufficient as making plain function
calls across process boundaries is impossible.
Cheers,
Albert
Paulo Martins
Tony,
You are right. Because of a bug in my application, sometimes
I called the HandleToObjet with values below 0x14. I found the bug,
did corrected it and my application is running well.
Thank you very much for your dedication on solving this
problem.
Cheers!
--
##################################################
# Paulo Martins
#-------------------------------------------------
# email: pau...@SPAMcorreionet.com.br
# ICQ - http://wwp.mirabilis.com/405933
# Remove the word "SPAM" above before reply.
##################################################
Tony Tanzillo wrote in message <6hefpm$sn...@adesknews2.autodesk.com>...
>Paulo - I modified your program to make it easier to
>experiement with. The .zip file is posted in the
>Customer files newsgroup, under the subject ACADOLE2.ZIP
>
>What I have found is that the crash does not happen
>if you avoid passing HandleToObject() handles that
>are < 0x14.
>
>Try running the enclosed .EXE and set the starting
>value to 20 (0x14), and note that you can run it
>as many times as you want, and it will not crash
>AutoCAD when you exit it.
>
>If you set the starting value to 1, then it will
>run all the way through the first time, and the
>second time, AutoCAD will throw an exception on
>the 15th iteration.
>
>I think your problem is solved by just avoiding
>handles that are less than 0x14.
>
>See the customerfiles newsgroup for the .ZIP file.
>
Tony Tanzillo
Paulo - An automation client can be placed into a .DLL
that also exposes another Automation object, which makes
the .DLL both a server and a client.
You can then load the .DLL into AutoCAD's process space
using the GetInterfaceObject() method, which allows it
to run much faster than a standalone automation client.
You can find an example in-process client/server on the
Delphi page of my web site.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6hg2ki$sn...@adesknews2.autodesk.com>...
>Hi Albert,
>
>Albert Szilvasy wrote in message <6hek4r$sn...@adesknews2.autodesk.com>...
>>Hi Paulo,
>>
>>I've looked into this problem and there's to be bug that will cause this
>>macro to fail the second time you run it. The bug is in the Automation
>>interface so the usual workaround applies here:
>>- Create an arx app and export either and Automation object or just a
>>function (for inpoc clients) that wraps the AcDbDatabase::getAcDbObjectId
>>function and use this object/function in your delphi app.
>>
>
>
>I'm familiarized with Visual C++, but I know just a little about ARX.
>
>Could you send me some directions or some example on how to
>export Automation Objects from an ARX Application?
>
>I know nothing about "inpoc clients". In fact, I never heard about it.
>Could you explain me what is it about ?
>
>>
>> I logged the bug in our tracking system so I hope this will be gone in the
>> next release.
>>
>Thanks!
>
Paulo Martins
Tony,
I get your example. Thanks! It's very didactical.
But I have a doubt yet. Albert suggested that I exported an Automation
object or a function
that wrapped the "AcDbDatabase::getAcDbObjectID". Is there a way to make a
function
that wraps "AcDbDatabase::getAcDbObjectID" from a Delphi server ?
I think that the only way to wrap AutoCAD function is by using ARX with
Visual C++.
So, the main utility of using inproc clients with Delphi is performance.
Am I right ?
--
##################################################
# Paulo Martins
#-------------------------------------------------
# email: pau...@SPAMcorreionet.com.br
# ICQ - http://wwp.mirabilis.com/405933
# Remove the word "SPAM" above before reply.
##################################################
Tony Tanzillo wrote in message <6hiitr$1b...@adesknews2.autodesk.com>...
Tony Tanzillo
Paulo - Are you saying that the problem still happens
if you avoid handles with values < 0x14? I'd like to
know.
You can't use Delphi to export ARX functions, you have
to use VC++. It's not hard to write an extension library,
but in this case, there is more to it than simply calling
AcDbDatabase::getAcDbObjectID() and returning the Object
ID. In this case, the code will have to determine what
kind of object is pointed to by the handle, and if there
is a COM wrapper for that object, and if so, then create
and return the COM wrapper object. For some objects (like
the MLINE), they return an IAcadEntity because there is
no interface for MLINES, so it's a bit more complicated
than Albert's advice suggests.
There are several advantages to using an in-process
automation client. The main advantage is speed.
Another is that your dialogs will be children of
the AutoCAD window, and behave like VBA dialogs
(e.g., you can create modal dialogs that do not
relinquish focus to the AutoCAD window).
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Paulo Martins wrote in message <6hla36$2m...@adesknews2.autodesk.com>...
Paulo Martins
Tony
Tony Tanzillo wrote in message <6hmq3b$2m...@adesknews2.autodesk.com>...
>Paulo - Are you saying that the problem still happens
>if you avoid handles with values < 0x14? I'd like to
>know.
>
No, avoiding pass handles < 0x14 the problem does not
happen. There was a bug in my application. Sometimes I
called the HandleToObject with values under 0x14. But know
I corrected the problem. Thank you!
>You can't use Delphi to export ARX functions, you have
>to use VC++. It's not hard to write an extension library,
>but in this case, there is more to it than simply calling
>AcDbDatabase::getAcDbObjectID() and returning the Object
>ID. In this case, the code will have to determine what
>kind of object is pointed to by the handle, and if there
>is a COM wrapper for that object, and if so, then create
>and return the COM wrapper object. For some objects (like
>the MLINE), they return an IAcadEntity because there is
>no interface for MLINES, so it's a bit more complicated
>than Albert's advice suggests.
>
>There are several advantages to using an in-process
>automation client. The main advantage is speed.
>
>Another is that your dialogs will be children of
>the AutoCAD window, and behave like VBA dialogs
>(e.g., you can create modal dialogs that do not
>relinquish focus to the AutoCAD window).
>
Thank you for the explanation!
Albert Szilvasy
Hi Tony,
You don't have to create the object. It suffices to return the id. Then the
client can call AcadDocument::ObjectIdToObject to get the object.
Albert
Tony Tanzillo wrote in message <6hmq3b$2m...@adesknews2.autodesk.com>...
>Paulo - Are you saying that the problem still happens
>if you avoid handles with values < 0x14? I'd like to
>know.
>
>You can't use Delphi to export ARX functions, you have
>to use VC++. It's not hard to write an extension library,
>but in this case, there is more to it than simply calling
>AcDbDatabase::getAcDbObjectID() and returning the Object
>ID. In this case, the code will have to determine what
>kind of object is pointed to by the handle, and if there
>is a COM wrapper for that object, and if so, then create
>and return the COM wrapper object. For some objects (like
>the MLINE), they return an IAcadEntity because there is
>no interface for MLINES, so it's a bit more complicated
>than Albert's advice suggests.
>
>There are several advantages to using an in-process
>automation client. The main advantage is speed.
>
>Another is that your dialogs will be children of
>the AutoCAD window, and behave like VBA dialogs
>(e.g., you can create modal dialogs that do not
>relinquish focus to the AutoCAD window).
>
>--
>/*********************************************************/
>/* Tony Tanzillo Design Automation Consulting */
>/* Programming & Customization for AutoCAD & Compatibles */
>/* ----------------------------------------------------- */
>/* Member of the OpenDWG Alliance */
>/* Co-Author of Maximizing AutoCAD R13 and */
>/* Maximizing AutoLISP for AutoCAD R13/R14 */
>/* ----------------------------------------------------- */
>/* tony.t...@worldnet.att.net */
>/* http://ourworld.compuserve.com/homepages/tonyt */
>/*********************************************************/
>Paulo Martins wrote in message <6hla36$2m...@adesknews2.autodesk.com>...
>>Tony,
>>
>>I get your example. Thanks! It's very didactical.
>>
>>But I have a doubt yet. Albert suggested that I exported an Automation
>>object or a function
>>that wrapped the "AcDbDatabase::getAcDbObjectID". Is there a way to make a
>>function
>>that wraps "AcDbDatabase::getAcDbObjectID" from a Delphi server ?
>>
>>I think that the only way to wrap AutoCAD function is by using ARX with
>>Visual C++.
>>
>>So, the main utility of using inproc clients with Delphi is performance.
>>
>>Am I right ?
>>
>>--
>>##################################################
>># Paulo Martins
>>#-------------------------------------------------
>># email: pau...@SPAMcorreionet.com.br
>># ICQ - http://wwp.mirabilis.com/405933
>># Remove the word "SPAM" above before reply.
>>##################################################
>>
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Albert Szilvasy
Hi Tony,
Objects that do not have a dedicated wrapper will be instantiated either as
AcadObject or AcadEntity. Anything in the drawing can be instantiated as
AcadObject. Besides, AcDbLayerTable has a wrapper that's the AcadLayers
object.
ArxAtl doesn't demonstrate anything except how simple it is to write such a
server.
Yes, arxatl will register itself upon loading. Yes, it can be registered
with LoadArx().
Hope this helps,
Albert
>Albert - Yes, but there is still the problem of handles
>of objects that have no object wrappers (like the layer
>table).
>
>Also, what does your ArxAtl example demonstrate (anything
>besides a skeleton ActiveX extension)?
>
>Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
>the problem that exists in Jorge's AcVbExt.dll, which can't
>properly register itself by loading the .DLL and calling
>DllRegisterServer() from a standalone executable?
>
>If so, can ArxAtl.dll be registered by just loading it
>with LoadArx()?
>
>
>--
>/*********************************************************/
>/* Tony Tanzillo Design Automation Consulting */
>/* Programming & Customization for AutoCAD & Compatibles */
>/* ----------------------------------------------------- */
>/* Member of the OpenDWG Alliance */
>/* Co-Author of Maximizing AutoCAD R13 and */
>/* Maximizing AutoLISP for AutoCAD R13/R14 */
>/* ----------------------------------------------------- */
>/* tony.t...@worldnet.att.net */
>/* http://ourworld.compuserve.com/homepages/tonyt */
>/*********************************************************/
>Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert - Yes, but there is still the problem of handles
of objects that have no object wrappers (like the layer
table).
Also, what does your ArxAtl example demonstrate (anything
besides a skeleton ActiveX extension)?
Is the acrxEntryPoint() in ArxAtl.cpp there to overcome
the problem that exists in Jorge's AcVbExt.dll, which can't
properly register itself by loading the .DLL and calling
DllRegisterServer() from a standalone executable?
If so, can ArxAtl.dll be registered by just loading it
with LoadArx()?
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Albert Szilvasy wrote in message <6hvv87$8r...@adesknews2.autodesk.com>...
Tony Tanzillo
Albert Szilvasy wrote in message <6i3idd$1f...@adesknews2.autodesk.com>...
>Hi Tony,
>
>Objects that do not have a dedicated wrapper will be instantiated either as
>AcadObject or AcadEntity. Anything in the drawing can be instantiated as
>AcadObject. Besides, AcDbLayerTable has a wrapper that's the AcadLayers
>object.
Okay, but that isn't what I'm getting.
When I call HandleToObject() with the handle of the layer
table (for example), a null pointer is returned (or is
this a known bug?).
>ArxAtl doesn't demonstrate anything except how simple it is to write such a
>server.
>Yes, arxatl will register itself upon loading. Yes, it can be registered
>with LoadArx().
Thanks. I'll try to adapt this to Jorge's AcVbExt.DLL.
Tony Tanzillo
Albert Szilvasy wrote in message <6i3idd$1f...@adesknews2.autodesk.com>...
>Hi Tony,
>
>Objects that do not have a dedicated wrapper will be instantiated either as
>AcadObject or AcadEntity. Anything in the drawing can be instantiated as
>AcadObject. Besides, AcDbLayerTable has a wrapper that's the AcadLayers
>object.
Okay, but that isn't what I'm getting.
When I call HandleToObject() with the handle of the layer
table (for example), a null pointer is returned (or is
this a known bug?).
>ArxAtl doesn't demonstrate anything except how simple it is to write such a
>server.
>Yes, arxatl will register itself upon loading. Yes, it can be registered
>with LoadArx().
Thanks. I'll try to adapt this to Jorge's AcVbExt.DLL.
--
Tony Tanzillo
Albert Szilvasy wrote in message <6i3idd$1f...@adesknews2.autodesk.com>...
>Hi Tony,
>
>Objects that do not have a dedicated wrapper will be instantiated either as
>AcadObject or AcadEntity. Anything in the drawing can be instantiated as
>AcadObject. Besides, AcDbLayerTable has a wrapper that's the AcadLayers
>object.
Okay, but that isn't what I'm getting.
When I call HandleToObject() with the handle of the layer
table (for example), a null pointer is returned (or is
this a known bug?).
>ArxAtl doesn't demonstrate anything except how simple it is to write such a
>server.
>Yes, arxatl will register itself upon loading. Yes, it can be registered
>with LoadArx().
Thanks. I'll try to adapt this to Jorge's AcVbExt.DLL.
--
Jorge Lopez
Tony,
>When I call HandleToObject() with the handle of the layer
>table (for example), a null pointer is returned (or is
>this a known bug?).
By searching the registry for AcDbLayerTable I found it is not registered.
Therefore, I am assuming they do not support IAcadBaseObject() and cache
AcDbObjectIds like the rest of the objects. This means the collection items
are not behaving like other objects in respect HandleToObject().
This issue is being looked at for fixing in the next version of AutoCAD.
Also, the problem with low handle values raising an error in
HandleToObject(). This has to do with a bug in the function called within
ObjectIdToObject(). It seems to only affect IAcadBlock objects created via
ObjectIdToObject() which is called from HandleToObject(). The low handle
values where likely the handles to *MODEL_SPACE or *PAPER_SPACE block table
records.
This was found and fixed after R14.01 was frozen. Therefore, the fix will be
in the next version of AutoCAD.
Sorry for the inconvenience.
Cheers,
Jorge Lopez
ActiveX/COM Development
Autodesk
Tony Tanzillo wrote in message <6i6h0h$1f...@adesknews2.autodesk.com>...
>Albert Szilvasy wrote in message <6i3idd$1f...@adesknews2.autodesk.com>...
>
>>Hi Tony,
>>
>>Objects that do not have a dedicated wrapper will be instantiated either
as
>>AcadObject or AcadEntity. Anything in the drawing can be instantiated as
>>AcadObject. Besides, AcDbLayerTable has a wrapper that's the AcadLayers
>>object.
>
>Okay, but that isn't what I'm getting.
>
>When I call HandleToObject() with the handle of the layer
>table (for example), a null pointer is returned (or is
>this a known bug?).
>
>>ArxAtl doesn't demonstrate anything except how simple it is to write such
a
>>server.
>>Yes, arxatl will register itself upon loading. Yes, it can be registered
>>with LoadArx().
>
>Thanks. I'll try to adapt this to Jorge's AcVbExt.DLL.
>
Tony Tanzillo
Jorge - Thanks for confirming these. In fact, it was
the *model_space block that was causing the exception.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/
Jorge Lopez wrote in message <6i8lu0$26...@adesknews2.autodesk.com>...
Tony Tanzillo
Jorge - Thanks for confirming these. In fact, it was
the *model_space block that was causing the exception.
--
/*********************************************************/
/* Tony Tanzillo Design Automation Consulting */
/* Programming & Customization for AutoCAD & Compatibles */
/* ----------------------------------------------------- */
/* Member of the OpenDWG Alliance */
/* Co-Author of Maximizing AutoCAD R13 and */
/* Maximizing AutoLISP for AutoCAD R13/R14 */
/* ----------------------------------------------------- */
/* tony.t...@worldnet.att.net */
/* http://ourworld.compuserve.com/homepages/tonyt */
/*********************************************************/