I commonly send serialized data to .net functions.
One of the items I send in the entity name of something as a string.
Once my .net function is done, it constructs a resultbuffer to send back to lisp.
I had been doing this:
AcDb.ObjectId id = new ObjectId(Convert.ToInt32(ename));
but the Convert function is throwing an exception.
I do not recall this happening before, but forget if I ever tested it.
I am on win 7 64 bit.
I thought the ename was a hex number, but am confused on it now.
Anyone got ideas to make it work?
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Hi,
looking into the signature of the construction method I see:
Public Sub New(oldId As Integer)
There is nothing written about "Int32" 😉
HTH, - alfred -
May be I don't understand your task
but this is from working code:
long lg = System.Convert.ToInt64(kvp.Key, 16);//kvp.Key contains Handle as string
Handle hd = new Handle(lg);
//get then the ObjectId from the Handle
ObjectId blkId = db.GetObjectId(false, hd, -1);
I saw the handle to objectid posts, but I am not dealing with a handle, but an entity name that you would get from the -1 group of and entget list from:
(entget (car (entsel)))
I have the entity name as a string in my .net prog, and want to send back a resultbuffer with the ename:
new TypedValue(-1, new ObjectId(Convert.ToInt32(ename)))
So I am wondering if the same tricks apply to handles and enames, in terms of data conversion.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
@Anonymous wrote:I saw the handle to objectid posts, but I am not dealing with a handle, but an entity name that you would get from the -1 group of and entget list from:
(entget (car (entsel)))
I have the entity name as a string in my .net prog, and want to send back a resultbuffer with the ename:
new TypedValue(-1, new ObjectId(Convert.ToInt32(ename)))
So I am wondering if the same tricks apply to handles and enames, in terms of data conversion.
My interpretation...
The first post says you are having issues with taking in the ename and converting to an ObjectId.
The second post says you are having issues sending the ename back.
The first post...
//check lisp arguments here
//then convert to an array
TypedValue[] args = rb.AsArray();
if (args[0].TypeCode != (short)LispDataType.ObjectId)
ObjectId objId = (ObjectId)args[0].Value
//start using transaction with try/catch...
//I'm usin a BlockTableRecord in my example.
BlockTableRecord btr = (BlockTableRecord)tr.GetObject(objId, OpenMode.ForRead, false);
//----------------------
//or just skip a step if you're not going to reuse ObjectId elsewhere
//BlockTableRecord btr = (BlockTableRecord)tr.GetObject((ObjectId)args[0].Value, OpenMode.ForRead, false);
For the secod post...
If your ename is the hex ename we see in autolisp, then...
ObjectId newObjId = new ObjectId(new IntPtr(Convert.ToInt64(hexEname, 16)));
If your ename is the string form of decimal for of the ename, then it's pretty much the same...
ObjectId newObjId = new ObjectId(new IntPtr(Convert.ToInt64(strDecEname)));
No need to send back a ResultBuffer if your just sending back the lisp ename object. Just return the TypedValue.
Hope this helps.
I'll try that, its been a while since I posted this.
thanks
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Hi,
While using the LispFunction argument to define a LISP function or using the Application.Invoke() method (or P/Invoking acedInvoke) to call a LISP function from .NET, an ename is automatically converted from or to a TypedValue with TypeCode = LispDataType.ObjectId.
As you said above
>> I commonly send serialized data to .net functions.
Would be good in this case to hold Handles instead of ObjectIds
in this case?
possibly, but one of my goals was to send all data from entget to .net, and back to lisp.
I do use handles, though, for anything that needs to recall another entity's name.
internal protected virtual unsafe Human() : mostlyHarmless
I'm just here for the Shelties
Even if you send the results of entget, you have a list that includes approx. two objects (enames) that will be converted to ObjectId's, as gile pointed out (ex. assoc -1 & 330)
Parsing the lisp data in .net, you will have a group of mostly dotted pairs (LispDataType.DottedPair) and these conses in the list will be the likes of...
(
(-1 . <Entity name: 7ffff605b90>) -> LispDataType.ObjectId
(0 . "LINE") -> LispDataType.Text
(330 . <Entity name: 7ffff6039f0>) -> LispDataType.ObjectId
(5 . "1B1") -> LispDataType.Text
(100 . "AcDbEntity") LispDataType.Text
(67 . 0) LispDataType.Int16??
(410 . "Model") LispDataType.Text
(8 . "0") LispDataType.Text
(100 . "AcDbLine") LispDataType.Text
(10 9.36013 9.3543 0.0) LispDataType.Point3d
(11 15.5982 8.93509 0.0) -> LispDataType.Point3d
(210 0.0 0.0 1.0) -> LispDataType.Point3d
)
As mentioned before, if you happen to get plain text ename in .net, then you can convert it
If your ename is the string hex ename we see in autolisp, then...
ObjectId newObjId = new ObjectId(new IntPtr(Convert.ToInt64(strHexEname, 16)));
If your ename is the string form of decimal for of the ename, then it's pretty much the same...
ObjectId newObjId = new ObjectId(new IntPtr(Convert.ToInt64(strDecEname)));
Reform the list above using the ObjectId's in place of enames nested in dotted pairs nested in a lisp...
ResultBuffer res = new Resultbuffer();
res.Add(new TypedValue((int)LispDataType.ListBegin));
res.add(new TypedValue((int)LispDataType.Int16, -1));
res.Add(new TypedValue((int)LispDataType.ObjectId, myPassingObjId)); //is received in lisp as an ename
res.Add(new TypedValue((int)LispDataType.DottedPair));
res.Add(new TypedValue((int)LispDataType.Int16, 0));
res.Add(new TypedValue((int)LispDataType.Text, strObjectTypeName));
res.Add(new TypedValue((int)LispDataType.DottedPair));
etc.
res.Add(new TypedValue((int)LispDataType.ListEnd));
- And you can entmod with what is returned.
All that to say, that you could just receive the ename, and use the ObjectId to get all the stuff off the .net object to rebuild your data to send back.