.NET

Reply
Active Member
brianroth
Posts: 10
Registered: ‎05-31-2005
Message 1 of 5 (149 Views)

Veto functionality bug?

149 Views, 4 Replies
09-29-2005 07:24 AM
Hi all,

Has anyone had any luck calling the Veto method in the DocumentLockModeChanged event? I'm trying to cancel the user's EATTEDIT command for some particular blocks. So in the DocumentLockModeChanged event I check for that command and block and then call e.Veto(). It doesn't error out, but it also doesn't stop the command. I'm wondering if there's a bug with the veto, since I set up an event for DocumentLockModeChangeVetoed and it doesn't hit that after I call veto.

Anyone else run into this? Here's what my code looks like:

void DocumentManager_DocumentLockModeChanged(object sender, DocumentLockModeChangedEventArgs e)
{
try
{
if (e.GlobalCommandName == "EATTEDIT" && IsSpecialBlock(e.Document))
{
// Block the edit
e.Veto();
}
}
catch { }
}
*Tony Tanzillo
Message 2 of 5 (149 Views)

Re: Veto functionality bug?

09-29-2005 08:47 AM in reply to: brianroth
The name of the event is DocumentLockModeChanged.

That is, 'Changed", in the past tense.

How can you veto something that has already happened?

More importantly, this isn't going to work in any case,
because the EATTEDIT dialog has a button that lets
the user select another block.

I was going to suggest using the Managed events on
the Editor (namely Editor.PromptForEntityEnding), but
that event is broken (more like FUBAR) and does not
allow you to selectively prevent selection of objects
(there seems to be some serious problems with the
event and the parameters passed to handlers).

You may be able to do this in native ObjectARX using
the AcEdSSGetFilter::endEntSel() function, but I haven't
actually tried it.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4970626@discussion.autodesk.com...
Hi all,

Has anyone had any luck calling the Veto method in the DocumentLockModeChanged event? I'm trying to cancel the user's EATTEDIT command for some particular blocks. So in the DocumentLockModeChanged event I check for that command and block and then call e.Veto(). It doesn't error out, but it also doesn't stop the command. I'm wondering if there's a bug with the veto, since I set up an event for DocumentLockModeChangeVetoed and it doesn't hit that after I call veto.

Anyone else run into this? Here's what my code looks like:

void DocumentManager_DocumentLockModeChanged(object sender, DocumentLockModeChangedEventArgs e)
{
try
{
if (e.GlobalCommandName == "EATTEDIT" && IsSpecialBlock(e.Document))
{
// Block the edit
e.Veto();
}
}
catch { }
}
Active Member
brianroth
Posts: 10
Registered: ‎05-31-2005
Message 3 of 5 (149 Views)

Re: Veto functionality bug?

09-29-2005 03:30 PM in reply to: brianroth
Thanks for the info, Tony. Not sure how I'll resolve it, but at least I know what doesn't work!
*Albert Szilvasy
Message 4 of 5 (149 Views)

Re: Veto functionality bug?

09-29-2005 10:53 PM in reply to: brianroth
Can you give me some more details on the PromptForEntityEnding bug that you
are seeing? I'd like to get it fixed.

albert

"Tony Tanzillo" wrote in message
news:4970767@discussion.autodesk.com...
The name of the event is DocumentLockModeChanged.

That is, 'Changed", in the past tense.

How can you veto something that has already happened?

More importantly, this isn't going to work in any case,
because the EATTEDIT dialog has a button that lets
the user select another block.

I was going to suggest using the Managed events on
the Editor (namely Editor.PromptForEntityEnding), but
that event is broken (more like FUBAR) and does not
allow you to selectively prevent selection of objects
(there seems to be some serious problems with the
event and the parameters passed to handlers).

You may be able to do this in native ObjectARX using
the AcEdSSGetFilter::endEntSel() function, but I haven't
actually tried it.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4970626@discussion.autodesk.com...
Hi all,

Has anyone had any luck calling the Veto method in the
DocumentLockModeChanged event? I'm trying to cancel the user's EATTEDIT
command for some particular blocks. So in the DocumentLockModeChanged event
I check for that command and block and then call e.Veto(). It doesn't error
out, but it also doesn't stop the command. I'm wondering if there's a bug
with the veto, since I set up an event for DocumentLockModeChangeVetoed and
it doesn't hit that after I call veto.

Anyone else run into this? Here's what my code looks like:

void DocumentManager_DocumentLockModeChanged(object sender,
DocumentLockModeChangedEventArgs e)
{
try
{
if (e.GlobalCommandName == "EATTEDIT" &&
IsSpecialBlock(e.Document))
{
// Block the edit
e.Veto();
}
}
catch { }
}
*Tony Tanzillo
Message 5 of 5 (149 Views)

Re: Veto functionality bug?

09-30-2005 09:07 AM in reply to: brianroth
The Result parameter of the event argument parameter is
always null, and the RemoveSelectedObject() method doesn't
seem to do what its name suggests. Given those things, the
event is of no use whatsoever, because you can't even find
out what object was selected.

private static void Editor_PromptForEntityEnding(object sender, PromptForEntityEndingEventArgs e)
{
Editor editor = (Editor) sender;
if( e.Result == null )
{
editor.WriteMessage("\nPromptForEntityEnding: e.Result == NULL !!!\n");

// This doesn't work at all.
e.RemoveSelectedObject();
return;
}

// simple test: try to prevent picking of any Circle

ObjectId id = e.Result.ObjectId;
using( Transaction tr = id.Database.TransactionManager.StartTransaction() )
{
DBObject o = tr.GetObject( id, OpenMode.ForRead );
if( o != null && o is Circle )
e.RemoveSelectedObject();
}
}


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

"Albert Szilvasy" wrote in message news:4971633@discussion.autodesk.com...
Can you give me some more details on the PromptForEntityEnding bug that you
are seeing? I'd like to get it fixed.

albert

"Tony Tanzillo" wrote in message
news:4970767@discussion.autodesk.com...
The name of the event is DocumentLockModeChanged.

That is, 'Changed", in the past tense.

How can you veto something that has already happened?

More importantly, this isn't going to work in any case,
because the EATTEDIT dialog has a button that lets
the user select another block.

I was going to suggest using the Managed events on
the Editor (namely Editor.PromptForEntityEnding), but
that event is broken (more like FUBAR) and does not
allow you to selectively prevent selection of objects
(there seems to be some serious problems with the
event and the parameters passed to handlers).

You may be able to do this in native ObjectARX using
the AcEdSSGetFilter::endEntSel() function, but I haven't
actually tried it.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2004/2005/2006
http://www.acadxtabs.com

wrote in message news:4970626@discussion.autodesk.com...
Hi all,

Has anyone had any luck calling the Veto method in the
DocumentLockModeChanged event? I'm trying to cancel the user's EATTEDIT
command for some particular blocks. So in the DocumentLockModeChanged event
I check for that command and block and then call e.Veto(). It doesn't error
out, but it also doesn't stop the command. I'm wondering if there's a bug
with the veto, since I set up an event for DocumentLockModeChangeVetoed and
it doesn't hit that after I call veto.

Anyone else run into this? Here's what my code looks like:

void DocumentManager_DocumentLockModeChanged(object sender,
DocumentLockModeChangedEventArgs e)
{
try
{
if (e.GlobalCommandName == "EATTEDIT" &&
IsSpecialBlock(e.Document))
{
// Block the edit
e.Veto();
}
}
catch { }
}
Post to the Community

Have questions about Autodesk products? Ask the community.

New Post
Announcements
Do you have 60 seconds to spare? The Autodesk Community Team is revamping our site ranking system and we want your feedback! Please click here to launch the 5 question survey. As always your input is greatly appreciated.