When it comes to display a custom dialog box we developed in AutoCAD (assuming we use System.Windows.Forms.Form), we all know that Autodesk wants you use Application.ShowModalDialog/ShowModelessDialog() instead of Form.ShowDialog()/Show().
The documentation from ObjectARX SDK only cited that using Form.Show()/ShowDialog() can cause AutoCAD behaving unexpectedly. It also points out one of the BENEFIT of using Application.ShowModalDialog()/ShowModelessDialog() is that AutoCAD remembers the dialog box' location and size when it is closed.
Well, it may be a benefit in an AutoCAD work environment where nothing changes once a user is assigned to use that computer. For me, this benefit has been minor or big disasters quite a few times!
Here are 2 typical cases that made me not very happy.
Case One.
In one of my project, when I I doing my final test run before a demo, since I use dual-monitor computer (who still doesn't?) I left AutoCAD showing in one screen and the dialog box in the other when the dialog box is closed.
Next day for the demo, I connected my computer to the projector. Naturally, it only has one screen played on the wall. When demo started, I was very confidently start my application. Why shouldn't I? I just test it many times. The application is supposed to pop up a dialog box. To my surprise, as soon as I entered my command, nothing happens and AutoCAD does not responding. OK, somehow the damn Widows freezes AutoCAD for some reason. It happens, right? So, I went to Task Manager to kill the AutoCAD process and tried it again. The same thing. One can imagine how embarrassing it was with coworkers in whole office sitting in meeting room for your demo and you cannot get the damn thing run. It was a bit fortunate I had something else to show that day, so that I did not have to quit the demo with nothing being talked.
Of course, it was the unexpected surprise hit my mind too hard that I did not realize the AutoCAD appearing to be frozen was because the dialog box was shown off the screen (e.g. in a non-existent second screen, thanks to AutoCAD so diligently remembered the dialog box' previous location and restored it there, even there was no extra screen). Since it is modal dialog box, thus AutoCAD shown on the main screen (the only screen at the time) appeared frozen.
Many of the uses of my applications uses a laptop. They may run AutoCAD (and may applications) with the laptop only, or with the laptop docked at their desk with multiple monitors. When using multiple monitor, user tend to move dialog box to one screen and AutoCAD main window in another. So, user often runs into this situation and think my application somehow crashes AutoCAD and seek help from me.
The immediate cure for this issue, if you do know it is because of a dialog box showing off screen, is to press "ALT+SPACE" and then press "M" key, following by pressing arrow key to move the invisible dialog box, or by holding mouse left key down and moving it around, until the dialog box can be seen on the screen.
Case Two.
I was in a project development. There was a dialog box. After a debugging run, AutoCAD dutifully remembered the dialog box' location and its size. However, at some point in the development, I decided to change the form's size to add more controls. So, I rearranged the form's layout (making it larger than previously. Now I run the application again, AutoCAD insisted to show the form in its previous size, thus part of the form was cut of. Since the form's border was set "FixedSingle" and/or "FixedDialog", not "Sizeable", I could not resize the form and close with it being in correct size. therefore AutoCAD would keep showing the form partially. See picture below.
AutoCAD shows this:
While the form should be:
I figured it is not uncommon as CAD application developer that you design a form, do some debugging run and then you change the size of the same form. In this case, I really do not need AutoCAD remember the form's size. Well, I could rename the form, I can fool AutoCAD to think it is a new form, so that AutoCAD would not set its size to previously remembered size. But it is a bit silly each time you change a form's size, you need to rename it.
So, I tried change the form's border type to "Sizeable", so in next debugging run, I can resize the form to proper size and hope AutoCAD remembers it. Then I change the form's border type back to "FixedSingle/Fixed3d/FixedDialog" again and run the project, in hoping now AutoCAD should use the correct form size. To my surprise, AutoCAD still uses the size when the form was in the fixed border type.
OK, short of renaming my form (I really do not want to), the only way I can get my form shown correctly, is to set the form's size in Form.Shown event handler with code. Note, the code that set form's size only works when Form's Shown event fires and thereafter. If you place the code in the form's constructor or in the Form.Load event handler, AutoCAD still force its remembered size/location. Obviously, Autodesk does the form location/size restoration after the form is loaded but right before it is shown.
So, what I have learned from this Application.ShowModalDialog() issue?
1. It is a bug for letting a dialog box be restored in a off-screen location. When AutoCAD tries to restore the form's previous location, it should check if the remembered location is off all available screens, if yes, it should show the dialog box based on the form's "StartPosition" property in the primary screen.
2. If we want to override AutoCAD and set the form's location/size with our code, the code should be in Form.Shown event handler. But I do wish the Application.ShowModalDialog/ShowModelessDialog() had a overload method where we can set flag to ask AutoCAD not to restore previous location/size.
3. I tried to use code in the Form.Shown event handler to get my form shown correctly and then close the form in the hope that AutoCAD now remembers the correct form size. At this point I removed the code in Form.Shown event handler, hoping now AutoCAD would restore the form in correct size. I ran the application again. AutoCAD still shows the form in its originally remembered size again, Apparently, for each form, if the form's border is fixed type, AutoCAD only remember its size the first time when the form shows (but it does remember form location each time the form is closed). So I have to keep the size setting code in Form.Shown events, unless I rename the form, or clean up my Windows account profile, both I reluctant to do.
Thursday, February 28, 2013
Sunday, February 17, 2013
Restoring a View with Aborted Transaction
In AutoCAD programming (or in general programming, for that matter), one of the best practices is that if your code changes some system status (such as system variables) just for your specific purpose, you should restore it back to its original status, if possible.
One of those things I had done many times before (quite long before, since I moved to use AutoCAD .NET API, when I worked with AutoLISP and VBA) was to create a temporary view before my code let user to do something in AutoCAD editor, usually it was to let user to zoom/pan the view or zoom/pan while selecting entities, and after that the code restore the view back and delete the temporary view. I was in this situation many times, so that I had LISP/VBA functions (to save a view and delete a view) in my tool box for reuse.
I also remembered it was emphasized in some popular AutoCAD user guide book (such as 'Master AutoCAD xxxx') that zooming it/out or panning too much that causes/requires 'regen' could be very slow/time consuming if the drawing size is big. Well, it was true considering the time when I was doing some drafting work with the computer of DOS/Windows 3.x/Windows 9x and 4MB/8MB memory. These book recommended to create view and save it before doing lots of zooming/panning, so that one can go back to the original view easily and quickly. I have hardly read any AutoCAD user guide book for many years since I stop doing drafting work, I am not sure if this is still recommended operation trick, but I'd not be surprised if it still is.
Anyway, back to the topic. I still find I am in the situation that I'd like to let the AutoCAD's current view look the same after running my code for something (mostly, it is to let user look at the entities in AutoCAD editor by hiding my modal dialog, or let user pick some entities, during which user need to zoom int/out or pan the view). So, my have reusable routines in my generic AutoCAD .NET tool box that does saving/restoring/deleting view (ViewTableRecord).
A question recently posted in Autodesk discussion group's .NET forum caught my attention: after the code asking user to pick entities, which results in zooming/panning, the view always automatically restored back to the status before the picking process started. It turned out it is due to the uncommitted (or aborted) Transaction that wrapped around the picking code.
As I admitted in the reply to that question, this is an interesting secrete of Transaction I had not noticed before: one starts a Transaction in order to get into individual entity for more information and somehow the Transaction grab current view information with it for some purpose behind the scene.
Without bothering to fully understand why, I thought at least I can use this to conveniently replace my "tedious" code of saving current view, restoring saved view and then deleting the saved view, and simply use an aborted Transaction to get the view back to it was after my code leads user zooming/panning in AutoCAD editor, assuming during the transaction, I only need to get read-only information from drawing database/entities (OpenMode.ForRead).
Here is the code that shows the situation: I want to user to pick some entities in the editor, but I'd like keep the view the same as before after picking is done. I used tow picking functions provided by Editor class: GetSelection() and GetEntity().
Here is command class to run the code
Running this code, in terms of restoring view to the status before picking is started, it is to my satisfactory: with only one extra line code (using (Transaction tran = ....){} (Transaction.Abort() can be omitted, but I like being explicit on this: committed, or aborted), I achieve the goal to keep the view unchanged after executing some code that very likely make the view changes. It is a lot easier than the way I used to do: saving current view, and later restore it back and then delete the saved view.
Oh, as side effect, I also noticed another thing I have never noticed before: Entity.Highlight() can be called with entity that is opened for read-only. In .NET API code practice so far, whenever I need to highlight an entity, I just took it for grant that the entity is opened for write. It looks like Entity.Highlight() does not involve the current Transaction.
Another issue you would notice by running this code: when selecting with Editor.GetEntity(), I call Entity.Highlight() on each picked entity to give user visual clue of which entity has been already selected. However, if the Transaction is done (aborted, in this case), although the view is restored back it what it was before, the entities highlighted by the code remain highlighted. This proves my guess just in above paragraph.
Depending on what you would do with the selected entities by code shown here, you can decide if you want the entities remaining highlighted or not. In my code sample here, I decide that I do not need them remaining highlighted, so I modified code to unhighlight the entities before the code returns. Here is the modified code:
I do not know if there would be some implications by using an aborted transaction to restore a view back. But in the situation I tend to use this approach (restoring a view back after asking user to pick some entities in most cases), it seems a simple and harmless way to do it.
One of those things I had done many times before (quite long before, since I moved to use AutoCAD .NET API, when I worked with AutoLISP and VBA) was to create a temporary view before my code let user to do something in AutoCAD editor, usually it was to let user to zoom/pan the view or zoom/pan while selecting entities, and after that the code restore the view back and delete the temporary view. I was in this situation many times, so that I had LISP/VBA functions (to save a view and delete a view) in my tool box for reuse.
I also remembered it was emphasized in some popular AutoCAD user guide book (such as 'Master AutoCAD xxxx') that zooming it/out or panning too much that causes/requires 'regen' could be very slow/time consuming if the drawing size is big. Well, it was true considering the time when I was doing some drafting work with the computer of DOS/Windows 3.x/Windows 9x and 4MB/8MB memory. These book recommended to create view and save it before doing lots of zooming/panning, so that one can go back to the original view easily and quickly. I have hardly read any AutoCAD user guide book for many years since I stop doing drafting work, I am not sure if this is still recommended operation trick, but I'd not be surprised if it still is.
Anyway, back to the topic. I still find I am in the situation that I'd like to let the AutoCAD's current view look the same after running my code for something (mostly, it is to let user look at the entities in AutoCAD editor by hiding my modal dialog, or let user pick some entities, during which user need to zoom int/out or pan the view). So, my have reusable routines in my generic AutoCAD .NET tool box that does saving/restoring/deleting view (ViewTableRecord).
A question recently posted in Autodesk discussion group's .NET forum caught my attention: after the code asking user to pick entities, which results in zooming/panning, the view always automatically restored back to the status before the picking process started. It turned out it is due to the uncommitted (or aborted) Transaction that wrapped around the picking code.
As I admitted in the reply to that question, this is an interesting secrete of Transaction I had not noticed before: one starts a Transaction in order to get into individual entity for more information and somehow the Transaction grab current view information with it for some purpose behind the scene.
Without bothering to fully understand why, I thought at least I can use this to conveniently replace my "tedious" code of saving current view, restoring saved view and then deleting the saved view, and simply use an aborted Transaction to get the view back to it was after my code leads user zooming/panning in AutoCAD editor, assuming during the transaction, I only need to get read-only information from drawing database/entities (OpenMode.ForRead).
Here is the code that shows the situation: I want to user to pick some entities in the editor, but I'd like keep the view the same as before after picking is done. I used tow picking functions provided by Editor class: GetSelection() and GetEntity().
1 using Autodesk.AutoCAD.ApplicationServices;
2 using Autodesk.AutoCAD.DatabaseServices;
3 using Autodesk.AutoCAD.EditorInput;
4 using Autodesk.AutoCAD.Geometry;
5 using Autodesk.AutoCAD.Runtime;
6 using System;
7 using System.Collections.Generic;
8 using System.Linq;
9 using System.Text;
10
11 namespace RestoreView
12 {
13 public static class AcadUtils
14 {
15 public static ObjectId[] SelectObjectsOnScreen(Document dwg)
16 {
17 List<ObjectId> selected = new List<ObjectId>();
18
19 using (Transaction tran = dwg.TransactionManager.StartTransaction())
20 {
21 ObjectId[] objIds = UseGetSelection(dwg.Editor);
22 selected.AddRange(objIds);
23 tran.Abort();
24 }
25
26 dwg.Editor.GetString("\nPress any key to continue <Enter>");
27
28 using (Transaction tran = dwg.TransactionManager.StartTransaction())
29 {
30 ObjectId[] objIds = UseGetEntity(dwg.Editor);
31 selected.AddRange(objIds);
32 tran.Abort();
33 }
34
35 return selected.ToArray();
36 }
37
38 private static ObjectId[] UseGetSelection(Editor ed)
39 {
40 PromptSelectionResult res = ed.GetSelection();
41 if (res.Status == PromptStatus.OK)
42 {
43 return res.Value.GetObjectIds();
44 }
45 else
46 {
47 return new ObjectId[0];
48 }
49 }
50
51 private static ObjectId[] UseGetEntity(Editor ed)
52 {
53 List<ObjectId> lst = new List<ObjectId>();
54
55 PromptEntityOptions opt =
56 new PromptEntityOptions("\nSelect a LINE or a CIRCLE:");
57 opt.SetRejectMessage("\nInvalid pick: must be either LINE or CIRCLE");
58 opt.AddAllowedClass(typeof(Line), true);
59 opt.AddAllowedClass(typeof(Circle), true);
60
61 while (true)
62 {
63 PromptEntityResult res = ed.GetEntity(opt);
64 if (res.Status != PromptStatus.OK) break;
65
66 if (lst.Contains(res.ObjectId))
67 {
68 ed.WriteMessage("\nDuplicate pick.");
69 }
70 else
71 {
72 Entity ent = (Entity)res.ObjectId.GetObject(OpenMode.ForWrite);
73 ent.Highlight();
74
75 lst.Add(res.ObjectId);
76 ed.WriteMessage("\n{0} object{1} selected.",
77 lst.Count, lst.Count > 1 ? "s" : "");
78 }
79 }
80
81 return lst.ToArray();
82 }
83 }
84 }
Here is command class to run the code
1 using Autodesk.AutoCAD.ApplicationServices;
2 using Autodesk.AutoCAD.DatabaseServices;
3 using Autodesk.AutoCAD.Runtime;
4
5 [assembly: CommandClass(typeof(RestoreView.MyCommands))]
6
7 namespace RestoreView
8 {
9 public class MyCommands
10 {
11 [CommandMethod("MySelect")]
12 public static void RunMyCommand()
13 {
14 Document dwg = Application.DocumentManager.MdiActiveDocument;
15
16 ObjectId[] ids = AcadUtils.SelectObjectsOnScreen(dwg);
17
18 dwg.Editor.WriteMessage("\nSelected objects: {0}", ids.Length);
19
20 Autodesk.AutoCAD.Internal.Utils.PostCommandPrompt();
21 }
22 }
23 }
Running this code, in terms of restoring view to the status before picking is started, it is to my satisfactory: with only one extra line code (using (Transaction tran = ....){} (Transaction.Abort() can be omitted, but I like being explicit on this: committed, or aborted), I achieve the goal to keep the view unchanged after executing some code that very likely make the view changes. It is a lot easier than the way I used to do: saving current view, and later restore it back and then delete the saved view.
Oh, as side effect, I also noticed another thing I have never noticed before: Entity.Highlight() can be called with entity that is opened for read-only. In .NET API code practice so far, whenever I need to highlight an entity, I just took it for grant that the entity is opened for write. It looks like Entity.Highlight() does not involve the current Transaction.
Another issue you would notice by running this code: when selecting with Editor.GetEntity(), I call Entity.Highlight() on each picked entity to give user visual clue of which entity has been already selected. However, if the Transaction is done (aborted, in this case), although the view is restored back it what it was before, the entities highlighted by the code remain highlighted. This proves my guess just in above paragraph.
Depending on what you would do with the selected entities by code shown here, you can decide if you want the entities remaining highlighted or not. In my code sample here, I decide that I do not need them remaining highlighted, so I modified code to unhighlight the entities before the code returns. Here is the modified code:
1 using Autodesk.AutoCAD.ApplicationServices;
2 using Autodesk.AutoCAD.DatabaseServices;
3 using Autodesk.AutoCAD.EditorInput;
4 using Autodesk.AutoCAD.Geometry;
5 using Autodesk.AutoCAD.Runtime;
6 using System;
7 using System.Collections.Generic;
8 using System.Linq;
9 using System.Text;
10
11 namespace RestoreView
12 {
13 public static class AcadUtils
14 {
15 public static ObjectId[] SelectObjectsOnScreen(Document dwg)
16 {
17 List<ObjectId> selected = new List<ObjectId>();
18
19 using (Transaction tran = dwg.TransactionManager.StartTransaction())
20 {
21 ObjectId[] objIds = UseGetSelection(dwg.Editor);
22 selected.AddRange(objIds);
23 tran.Abort();
24 }
25
26 dwg.Editor.GetString("\nPress any key to continue <Enter>");
27
28 using (Transaction tran = dwg.TransactionManager.StartTransaction())
29 {
30 ObjectId[] objIds = UseGetEntity(dwg.Editor);
31 selected.AddRange(objIds);
32 tran.Abort();
33 }
34
35 return selected.ToArray();
36 }
37
38 private static ObjectId[] UseGetSelection(Editor ed)
39 {
40 PromptSelectionResult res = ed.GetSelection();
41 if (res.Status == PromptStatus.OK)
42 {
43 return res.Value.GetObjectIds();
44 }
45 else
46 {
47 return new ObjectId[0];
48 }
49 }
50
51 private static ObjectId[] UseGetEntity(Editor ed)
52 {
53 List<ObjectId> lst = new List<ObjectId>();
54
55 PromptEntityOptions opt =
56 new PromptEntityOptions("\nSelect a LINE or a CIRCLE:");
57 opt.SetRejectMessage("\nInvalid pick: must be either LINE or CIRCLE");
58 opt.AddAllowedClass(typeof(Line), true);
59 opt.AddAllowedClass(typeof(Circle), true);
60
61 while (true)
62 {
63 PromptEntityResult res = ed.GetEntity(opt);
64 if (res.Status != PromptStatus.OK) break;
65
66 if (lst.Contains(res.ObjectId))
67 {
68 ed.WriteMessage("\nDuplicate pick.");
69 }
70 else
71 {
72 Entity ent = (Entity)res.ObjectId.GetObject(OpenMode.ForWrite);
73 ent.Highlight();
74
75 lst.Add(res.ObjectId);
76 ed.WriteMessage("\n{0} object{1} selected.",
77 lst.Count, lst.Count > 1 ? "s" : "");
78 }
79 }
80
81 Unhighlight(lst.ToArray());
82
83 return lst.ToArray();
84 }
85
86 private static void Unhighlight(ObjectId[] ids)
87 {
88 foreach (ObjectId id in ids)
89 {
90 Entity ent = (Entity)id.GetObject(OpenMode.ForRead);
91 ent.Unhighlight();
92 }
93 }
94 }
95 }
I do not know if there would be some implications by using an aborted transaction to restore a view back. But in the situation I tend to use this approach (restoring a view back after asking user to pick some entities in most cases), it seems a simple and harmless way to do it.
Wednesday, January 2, 2013
Enhance Code Performance with Document.UserData
Kean Walmsley had a post quite a few years ago on the topic of Document.UserData, which is a HashTable type of object associated to the each document opened in AutoCAD. UserData can be used to store any type of data (type of object) identified by a unique key (type of string). To be aware, though, Document.UserData only available with opened document and is not persisted with the document. That is, it not part of drawing database, and only stays in memory with opened drawing document.
With the help of Document.UserData, it is possible to enhance our code performance in some cases. Here are a couple of scenarios.
1. Sometimes, we may need to search entire drawing fore some information before further process can continue. For example, I may want to get a some information of all entities that have Xdata embedded with certain application name. If the the drawing has tens of thousands of entities, the search could take some time.
After the search there could be different processes being performed based on the data obtained by the search. We certainly do not want to repeat the search each time a process based on the data obtained by the search, if possible. So, we could save the search result in Document.UserData when the search is complete. Then when following processes need the searched data, they can simply retrieve it from Document.UserData.
Well, in this case, it seems not much different from using class member variable when a command class is instantiated by a not-static command method. So, it is just another way to do things.
2. We can use Document.UserData to pass data between projects (DLLs). For example, I plan to do a set of tools that will run on a set of data, which could be based on a heavy drawing search or external database/service search. In this case, I can plan my development into multiple projects (agile development, delivering my workable tools one by one). So, I have one project doing the data gathering and store the obtained data in Document.UserData as in instance of a class (called Class1). In each individual tool project, it always go to Document.UserData to see if there is an object of Class1 stored or not. If it is, no data gathering is required and the tool's operation goes ahead.
Of course, if the data obtained in searching process could be changed, then some mechanism should be in place to refresh the data stored in Document.UserData. For example, if the data is related to per entity information, we may handle Database.ObjectModified event and determine if related information has been changed, hence the data in Document.UserData should be refreshed.
With the help of Document.UserData, it is possible to enhance our code performance in some cases. Here are a couple of scenarios.
1. Sometimes, we may need to search entire drawing fore some information before further process can continue. For example, I may want to get a some information of all entities that have Xdata embedded with certain application name. If the the drawing has tens of thousands of entities, the search could take some time.
After the search there could be different processes being performed based on the data obtained by the search. We certainly do not want to repeat the search each time a process based on the data obtained by the search, if possible. So, we could save the search result in Document.UserData when the search is complete. Then when following processes need the searched data, they can simply retrieve it from Document.UserData.
Well, in this case, it seems not much different from using class member variable when a command class is instantiated by a not-static command method. So, it is just another way to do things.
2. We can use Document.UserData to pass data between projects (DLLs). For example, I plan to do a set of tools that will run on a set of data, which could be based on a heavy drawing search or external database/service search. In this case, I can plan my development into multiple projects (agile development, delivering my workable tools one by one). So, I have one project doing the data gathering and store the obtained data in Document.UserData as in instance of a class (called Class1). In each individual tool project, it always go to Document.UserData to see if there is an object of Class1 stored or not. If it is, no data gathering is required and the tool's operation goes ahead.
Of course, if the data obtained in searching process could be changed, then some mechanism should be in place to refresh the data stored in Document.UserData. For example, if the data is related to per entity information, we may handle Database.ObjectModified event and determine if related information has been changed, hence the data in Document.UserData should be refreshed.
Thursday, December 27, 2012
Custom Double-Click Action Using Application.BeginDoubleClick Event
I cannot remember since when AutoCAD introduced double-click editing mechanism, which is a great shortcut to a default command against particular type of entities. The default command that is supposed to take action when user double-clicks an entity is defined in the "Double Click Actions" part of the loaded CUI/CUIX file.
The "Double Click Actions" part in CUIX can be manually or programmatically modified according to the need. This makes it very easy to customize Double Click Actions differently from the default actions. With this approach, only one action (command) can be associated to each type of Entity. While in reality, however, we might want AutoCAD to act differently when user double-clicks the same types of entities. For example, when a line is double-clicked, we may want to do one thing, depending on some conditions and do other thing under different condition; if a block is double-clicked, depending on its name or its attributes, we may want to present different dialog boxes; and so on.
There is long thread of discussion on this topic in AutoCAD discussion forum here. Based on the discussion, Balaji Ramamoorthy posted a solution, which places some logic in the command that associated with "Double Click Actions" in the CUI/CUIX, so that the actual action taken against the selected entity or entities could be different, depending on particular conditions.
Be aware that the solution for custom double-click action based on modifying "Double Click Actions" in CUI/CUIX has a pre-condition: the system variable "DBLCLKEDIT" must be set to 1. If for any reason this system variable is set to 0, all the double-click actions defined in the CUI/CUIX will stop work. Also, changing CUI/CUIX (and saving the changes) with code may not be preferred in some tightly managed drafting environment.
Here I post code samples that uses Application.BeginDoubleClick event handler to realize desired custom double-click actions.
Up to AutoCAD 2009, there is no Application.BeginDoubleClick event exposed in AutoCAD's .NET API. Well, with AutoCAD's COM API does expose a AcadDocument.BeginDoubleClick event, but because there is lack of means to suppress the default double-click action (defined in the CUI/CUIX), thus, the COM API's BeginDoubleClick event does not help in term of doing custom double-click action.
The thoughts of using Application.BeginDoubleClick event to do our own custom double-click actions is like this:
1. Application.BeginDoubleClick event always fires, regardless the value of system variable "DBLCLKEDIT". That means we can guarantee that our own custom double-click action will work as we want;
2. When Application.BegnDoubleClick event fires, we can get the entity or entities selected by the double-click and apply some logic against the entity or entities to determine if we want to let default double-click action do its work, or let particular custom double-click action do its work; If the logic decides that a custom double-click action should be used, then we use DocumentLockModeChanged event handler to veto the default double-click action and use DocumentLockModeChangeVetoed event handler to launch the desired custom double-click action.
With these thoughts in mind, I worked out some code posted here.
Firstly, I need something that can be used to determine if a custom command would be used when Application.BeginDoubleClick event fires. The available information for making the decision is ObjectId of the selected entity. So, I create an Interface like this:
Then I implement this interface for each targeting entity type (just like how is "Double Click Actions" in CUI/CUIX defined for each entity type). In the sample project, I only implemented this interface for 2 types of entity: Line and BlockReference. See code below:
From these 2 ICustomCommandMapper classes one can see there is literally no limit how many custom commands can come out the method GetMappedCustomCommand(), depending on what operation one want to apply to the target type of entity. Take BlockReference as an example: it is very practical that we may want to show different dialog box for editing block and/or block attribute, if the selected block has different name.
Of course, corresponding to the custom commands that are returned by the GetMappedCustomCommand(), I have following command methods that mimic different custom actions (showing different messages in message box):
In order to use the ICustumCommandMapper classes easily, I also created a CustomCommandMappers collection, derived from Dictionary. Here I use Type as the collection's key, so that each entity type will only have one ICustomCommandMapper class. Also, I use the Factory pattern to create the instance of CustomCommandMappers class, which would make it easy to create instance of CustomCommandMapper class in different environment, such as from some sort of configurable settings (which I did not implement it here, for simplicity). Here is the code:
Now it comes to the centre piece of the code - actually handling the Application.BeginDoubleClick to let AutoCAD intelligently launch default Double Click Action defined in CUI/CUIX or launch our custom action, even with system variable "DBLCLKEDIT" is disabled:
This video clip shows the code in action.
If reading the code carefully, one should realize that when "DBLCLKEDIT" is enabled, the custom command only launched when the default double-click command defined in CUI/CUIX is vetoed. That means if there is no default double-click command defined in CUI/CUIX defined for particular entity type, then the DocumentLockModeVetoed event will not fire, hence the custom command will not be launched.
The "Double Click Actions" part in CUIX can be manually or programmatically modified according to the need. This makes it very easy to customize Double Click Actions differently from the default actions. With this approach, only one action (command) can be associated to each type of Entity. While in reality, however, we might want AutoCAD to act differently when user double-clicks the same types of entities. For example, when a line is double-clicked, we may want to do one thing, depending on some conditions and do other thing under different condition; if a block is double-clicked, depending on its name or its attributes, we may want to present different dialog boxes; and so on.
There is long thread of discussion on this topic in AutoCAD discussion forum here. Based on the discussion, Balaji Ramamoorthy posted a solution, which places some logic in the command that associated with "Double Click Actions" in the CUI/CUIX, so that the actual action taken against the selected entity or entities could be different, depending on particular conditions.
Be aware that the solution for custom double-click action based on modifying "Double Click Actions" in CUI/CUIX has a pre-condition: the system variable "DBLCLKEDIT" must be set to 1. If for any reason this system variable is set to 0, all the double-click actions defined in the CUI/CUIX will stop work. Also, changing CUI/CUIX (and saving the changes) with code may not be preferred in some tightly managed drafting environment.
Here I post code samples that uses Application.BeginDoubleClick event handler to realize desired custom double-click actions.
Up to AutoCAD 2009, there is no Application.BeginDoubleClick event exposed in AutoCAD's .NET API. Well, with AutoCAD's COM API does expose a AcadDocument.BeginDoubleClick event, but because there is lack of means to suppress the default double-click action (defined in the CUI/CUIX), thus, the COM API's BeginDoubleClick event does not help in term of doing custom double-click action.
The thoughts of using Application.BeginDoubleClick event to do our own custom double-click actions is like this:
1. Application.BeginDoubleClick event always fires, regardless the value of system variable "DBLCLKEDIT". That means we can guarantee that our own custom double-click action will work as we want;
2. When Application.BegnDoubleClick event fires, we can get the entity or entities selected by the double-click and apply some logic against the entity or entities to determine if we want to let default double-click action do its work, or let particular custom double-click action do its work; If the logic decides that a custom double-click action should be used, then we use DocumentLockModeChanged event handler to veto the default double-click action and use DocumentLockModeChangeVetoed event handler to launch the desired custom double-click action.
With these thoughts in mind, I worked out some code posted here.
Firstly, I need something that can be used to determine if a custom command would be used when Application.BeginDoubleClick event fires. The available information for making the decision is ObjectId of the selected entity. So, I create an Interface like this:
1 using Autodesk.AutoCAD.DatabaseServices;
2
3 namespace DoubleClickHandler
4 {
5 public interface ICustomCommandMapper
6 {
7 string GetMappedCustomCommand(ObjectId entId);
8 }
9 }
Then I implement this interface for each targeting entity type (just like how is "Double Click Actions" in CUI/CUIX defined for each entity type). In the sample project, I only implemented this interface for 2 types of entity: Line and BlockReference. See code below:
1 using System;
2 using System.Collections.Generic;
3 using Autodesk.AutoCAD.DatabaseServices;
4 using Autodesk.AutoCAD.Geometry;
5 using Autodesk.AutoCAD.Runtime;
6
7 namespace DoubleClickHandler
8 {
9 public class LineCustomCommandMapper : ICustomCommandMapper
10 {
11 private Type _entityType;
12 private RXClass _rxClass;
13
14 public LineCustomCommandMapper()
15 {
16 _entityType = typeof(Line);
17 _rxClass = RXClass.GetClass(_entityType);
18 }
19
20 public Type EntityType
21 {
22 get { return _entityType; }
23 }
24
25 public string GetMappedCustomCommand(ObjectId entId)
26 {
27 if (entId.ObjectClass != _rxClass) return null;
28
29 //Do something based on the ObjectId. For example:
30 //if the entity has XData attached, the attached
31 //data may decide what command to use
32
33 //Here I use simply use Line's geometric info:
34 //If the line is drawn from left to right, or
35 //from right to left
36 Point3d sPt;
37 Point3d ePt;
38 Database db = entId.Database;
39 using (Transaction tran =
40 db.TransactionManager.StartOpenCloseTransaction())
41 {
42 Line line = (Line)tran.GetObject(entId, OpenMode.ForRead);
43 sPt = line.StartPoint;
44 ePt = line.EndPoint;
45 tran.Commit();
46 }
47
48 if (sPt.X < ePt.X)
49 return "MyLineEditCommand1";
50 else
51 return "MyLineEditCommand2";
52 }
53 }
54
55 public class BlockCustomCommandMapper : ICustomCommandMapper
56 {
57 private Type _entityType;
58 private RXClass _rxClass;
59 private Dictionary<string, string> _dicCommands;
60
61 public BlockCustomCommandMapper(Dictionary<string, string> blkEditCommands)
62 {
63 _entityType = typeof(BlockReference);
64 _rxClass = RXClass.GetClass(_entityType);
65 _dicCommands = blkEditCommands;
66 }
67
68 public Type EntityType
69 {
70 get { return _entityType; }
71 }
72
73 public string GetMappedCustomCommand(ObjectId entId)
74 {
75 if (entId.ObjectClass != _rxClass) return null;
76
77 //Do something based on the ObjectId. For example:
78 //if the entity has XData attached, tne attached
79 //data may decide what command to use
80
81 //As for block, different command usually is chosen
82 //based on different block name
83 string bName = GetBlockName(entId);
84
85 if (_dicCommands.ContainsKey(bName.ToUpper()))
86 {
87 return _dicCommands[bName.ToUpper()];
88 }
89
90 return null;
91 }
92
93 private static string GetBlockName(ObjectId entId)
94 {
95 string blkName = "";
96
97 using (Transaction tran =
98 entId.Database.TransactionManager.StartOpenCloseTransaction())
99 {
100 BlockReference bref = (BlockReference)
101 tran.GetObject(entId, OpenMode.ForRead);
102
103 if (bref.IsDynamicBlock)
104 {
105 if (bref.Name.StartsWith("*"))
106 {
107 BlockTableRecord br = (BlockTableRecord)
108 tran.GetObject(bref.DynamicBlockTableRecord, OpenMode.ForRead);
109 blkName = br.Name;
110 }
111 else
112 {
113 blkName = bref.Name;
114 }
115 }
116 else
117 {
118 blkName = bref.Name;
119 }
120
121 tran.Commit();
122 }
123
124 return blkName;
125 }
126 }
127 }
From these 2 ICustomCommandMapper classes one can see there is literally no limit how many custom commands can come out the method GetMappedCustomCommand(), depending on what operation one want to apply to the target type of entity. Take BlockReference as an example: it is very practical that we may want to show different dialog box for editing block and/or block attribute, if the selected block has different name.
Of course, corresponding to the custom commands that are returned by the GetMappedCustomCommand(), I have following command methods that mimic different custom actions (showing different messages in message box):
1 using Autodesk.AutoCAD.ApplicationServices;
2 using Autodesk.AutoCAD.DatabaseServices;
3 using Autodesk.AutoCAD.EditorInput;
4 using Autodesk.AutoCAD.Runtime;
5
6 [assembly: CommandClass(typeof(DoubleClickHandler.CustomCommands))]
7
8 namespace DoubleClickHandler
9 {
10 public class CustomCommands
11 {
12 #region Commands for LineCustomCommandMapper
13
14 [CommandMethod("MyLineEditCommand1", CommandFlags.UsePickSet)]
15 public void RunMyLineEditCommand1()
16 {
17 ObjectId entId = GetSelectedEntity();
18 if (entId == ObjectId.Null) return;
19
20 string msg =
21 "This is a dialog box for editing LINE entity drawn from left to right." +
22 "\n\nEntity Id=" + entId.ToString();
23 Application.ShowAlertDialog(msg);
24 }
25
26 [CommandMethod("MyLineEditCommand2", CommandFlags.UsePickSet)]
27 public void RunMyLineEditCommand2()
28 {
29 ObjectId entId = GetSelectedEntity();
30 if (entId == ObjectId.Null) return;
31
32 string msg =
33 "This is a dialog box for editing LINE entity drawn from right to left." +
34 "\n\nEntity Id=" + entId.ToString();
35 Application.ShowAlertDialog(msg);
36 }
37
38 #endregion
39
40 #region Commands for BlockCustomCommandMapper
41
42 [CommandMethod("BlockEditCommand1", CommandFlags.UsePickSet)]
43 public void RunBlockEditCommand1()
44 {
45 ObjectId entId = GetSelectedEntity();
46 if (entId == ObjectId.Null) return;
47
48 string msg = "This is a dialog box for editing block \"TestBlock1\"." +
49 "\n\nEntity Id=" + entId.ToString();
50 Application.ShowAlertDialog(msg);
51 }
52
53 [CommandMethod("BlockEditCommand2", CommandFlags.UsePickSet)]
54 public void RunBlockEditCommand2()
55 {
56 ObjectId entId = GetSelectedEntity();
57 if (entId == ObjectId.Null) return;
58
59 string msg = "This is a dialog box for editing block \"TestBlock2\"." +
60 "\n\nEntity Id=" + entId.ToString();
61 Application.ShowAlertDialog(msg);
62 }
63
64 #endregion
65
66 #region private methods
67
68 private ObjectId GetSelectedEntity()
69 {
70 Editor ed=Application.DocumentManager.MdiActiveDocument.Editor;
71 PromptSelectionResult res = ed.GetSelection();
72
73 if (res.Status == PromptStatus.OK)
74 {
75 return res.Value.GetObjectIds()[0];
76 }
77 else
78 {
79 return ObjectId.Null;
80 }
81 }
82
83 #endregion
84 }
85 }
In order to use the ICustumCommandMapper classes easily, I also created a CustomCommandMappers collection, derived from Dictionary
1 using System;
2 using System.Collections.Generic;
3 using Autodesk.AutoCAD.DatabaseServices;
4
5 namespace DoubleClickHandler
6 {
7 public class CustomCommandMappers : Dictionary<Type, ICustomCommandMapper>
8 {
9 public string GetCustomCommand(ObjectId entId)
10 {
11 string cmd = null;
12
13 foreach (KeyValuePair<Type, ICustomCommandMapper> item in this)
14 {
15 ICustomCommandMapper custCommand = item.Value;
16 string c = custCommand.GetMappedCustomCommand(entId);
17 if (!string.IsNullOrEmpty(c))
18 {
19 cmd = c;
20 break;
21 }
22 }
23
24 return cmd;
25 }
26 }
27
28 public class CustomCommandsFactory
29 {
30 public static CustomCommandMappers CreateDefaultCustomCommandMappers()
31 {
32 CustomCommandMappers cmds = new CustomCommandMappers();
33
34 //Manually create 2 instances of ICustomCOmmandMapper object
35 //for demo purpose
36 ICustomCommandMapper cmd;
37
38 cmd = new LineCustomCommandMapper();
39 cmds.Add(typeof(Line), cmd);
40
41 Dictionary<string, string> dic = new Dictionary<string, string>();
42 dic.Add("TESTBLOCK1", "BlockEditCommand1");
43 dic.Add("TESTBLOCK2", "BlockEditCommand2");
44 cmd = new BlockCustomCommandMapper(dic);
45 cmds.Add(typeof(BlockReference), cmd);
46
47 return cmds;
48 }
49
50 public static CustomCommandMappers CreateCustomCommandMappersFromSettings()
51 {
52 //We can define information required by ICustomCommandMapper
53 //in some sort of configurable application settings, such as acad.exe.config,
54 //and implement this method to loaded it.
55 throw new NotImplementedException("This method is not implemented.");
56 }
57 }
58 }
Now it comes to the centre piece of the code - actually handling the Application.BeginDoubleClick to let AutoCAD intelligently launch default Double Click Action defined in CUI/CUIX or launch our custom action, even with system variable "DBLCLKEDIT" is disabled:
1 using Autodesk.AutoCAD.ApplicationServices;
2 using Autodesk.AutoCAD.DatabaseServices;
3 using Autodesk.AutoCAD.EditorInput;
4 using Autodesk.AutoCAD.Runtime;
5
6 [assembly: CommandClass(typeof(DoubleClickHandler.AppDoubleClickHandler))]
7 [assembly: ExtensionApplication(typeof(DoubleClickHandler.AppDoubleClickHandler))]
8
9 namespace DoubleClickHandler
10 {
11 public class AppDoubleClickHandler : IExtensionApplication
12 {
13 private static bool _handlerLoaded = false;
14 private static string _customCmd = null;
15 private static ObjectId _selectedEntId = ObjectId.Null;
16 private static CustomCommandMappers _customCommands = null;
17 private static bool _runCustomCommand = false;
18
19 public void Initialize()
20 {
21 Document dwg = Application.DocumentManager.MdiActiveDocument;
22 Editor ed = dwg.Editor;
23
24 try
25 {
26 ed.WriteMessage("\nInitializing {0}...", this.GetType().Name);
27
28 AddDoubleClickHandler();
29
30 ed.WriteMessage("completed\n");
31
32 ed.WriteMessage("\nMy Double-Click Handler has been turned {0}.",
33 _handlerLoaded ? "on" : "off");
34 Autodesk.AutoCAD.Internal.Utils.PostCommandPrompt();
35 }
36 catch (System.Exception ex)
37 {
38 ed.WriteMessage("failed:\n{0}", ex.ToString());
39 }
40 }
41
42 public void Terminate()
43 {
44
45 }
46
47 //Command to toggle this Double-Click handler on or off
48 [CommandMethod("MyDblClick", CommandFlags.Session)]
49 public static void ToggleDoubleClickHandling()
50 {
51 Document dwg = Application.DocumentManager.MdiActiveDocument;
52 Editor ed = dwg.Editor;
53
54 PromptKeywordOptions opt = new PromptKeywordOptions(
55 "\nToggle My Double-Click Handler on/off");
56 opt.Keywords.Add("oN");
57 opt.Keywords.Add("oFf");
58 opt.Keywords.Default = _handlerLoaded ? "oN" : "oFf";
59 opt.AppendKeywordsToMessage = true;
60 PromptResult res = ed.GetKeywords(opt);
61 if (res.StringResult.ToUpper() == "ON")
62 AddDoubleClickHandler();
63 else
64 RemoveDoubleClickHandler();
65
66 ed.WriteMessage("\nMy Double-Click Handler has been turned {0}.",
67 _handlerLoaded?"on":"off");
68 Autodesk.AutoCAD.Internal.Utils.PostCommandPrompt();
69 }
70
71 #region private methods
72
73 private static void AddDoubleClickHandler()
74 {
75 if (_handlerLoaded) return;
76
77 Application.BeginDoubleClick += Application_BeginDoubleClick;
78 Application.DocumentManager.DocumentLockModeChanged +=
79 DocumentManager_DocumentLockModeChanged;
80 Application.DocumentManager.DocumentLockModeChangeVetoed +=
81 DocumentManager_DocumentLockModeChangeVetoed;
82 _handlerLoaded = true;
83
84 //Load custom command mappers
85 if (_customCommands == null) _customCommands =
86 CustomCommandsFactory.CreateDefaultCustomCommandMappers();
87 }
88
89 private static void RemoveDoubleClickHandler()
90 {
91 if (!_handlerLoaded) return;
92
93 Application.BeginDoubleClick -= Application_BeginDoubleClick;
94 Application.DocumentManager.DocumentLockModeChanged -=
95 DocumentManager_DocumentLockModeChanged;
96 Application.DocumentManager.DocumentLockModeChangeVetoed -=
97 DocumentManager_DocumentLockModeChangeVetoed;
98
99 _customCommands = null;
100
101 _handlerLoaded = false;
102 }
103
104 private static void Application_BeginDoubleClick(
105 object sender, BeginDoubleClickEventArgs e)
106 {
107 _customCmd = null;
108 _selectedEntId = ObjectId.Null;
109
110 //Get entity which user double-clicked on
111 Editor ed=Application.DocumentManager.MdiActiveDocument.Editor;
112 PromptSelectionResult res = ed.SelectImplied();
113 if (res.Status == PromptStatus.OK)
114 {
115 ObjectId[] ids = res.Value.GetObjectIds();
116
117 //Only when there is one entity selected, we go ahead to see
118 //if there is a custom command supposed to target at this entity
119 if (ids.Length == 1)
120 {
121 //Find mapped custom command name
122 string cmd = _customCommands.GetCustomCommand(ids[0]);
123 if (!string.IsNullOrEmpty(cmd))
124 {
125 _selectedEntId = ids[0];
126 _customCmd = cmd;
127
128 ed.WriteMessage("\nRun command {0} agianst entity {1}",
129 _customCmd, _selectedEntId.ToString());
130
131 if (System.Convert.ToInt32(
132 Application.GetSystemVariable("DBLCLKEDIT")) == 0)
133 {
134 //Since "Double click editing" is not enabled, we'll
135 //go ahead to launch our custom command
136 LaunchCustomCommand(ed);
137 }
138 else
139 {
140 //Since "Double Click Editing" is enabled, a command
141 //defined in CUI/CUIX will be fired. Let the code return
142 //and wait the DocumentLockModeChanged and
143 //DocumentLockModeChangeVetoed event handlers do their job
144 return;
145 }
146 }
147 else
148 {
149 ed.WriteMessage(
150 "\nNo custom command is defined agaist the selected entity.");
151 }
152 }
153 }
154 else
155 {
156 ed.WriteMessage("\nNo entity or more than 1 entities selected.");
157 }
158 }
159
160 private static void DocumentManager_DocumentLockModeChanged(
161 object sender, DocumentLockModeChangedEventArgs e)
162 {
163 _runCustomCommand = false;
164 Editor ed = Application.DocumentManager.MdiActiveDocument.Editor;
165
166 if (e.GlobalCommandName.Length > 0)
167 {
168 if (_selectedEntId != ObjectId.Null &&
169 !string.IsNullOrEmpty(_customCmd) &&
170 e.GlobalCommandName.ToUpper() != _customCmd.ToUpper())
171 {
172 ed.WriteMessage(
173 "\nCommand {0} is vetoed!", e.GlobalCommandName);
174
175 e.Veto();
176 _runCustomCommand = true;
177 }
178 }
179 }
180
181 private static void DocumentManager_DocumentLockModeChangeVetoed(
182 object sender, DocumentLockModeChangeVetoedEventArgs e)
183 {
184 Editor ed = Application.DocumentManager.MdiActiveDocument.Editor;
185
186 if (_runCustomCommand)
187 {
188 ed.WriteMessage(
189 "\nNow running custom command {0} against entity {1}",
190 _customCmd, _selectedEntId.ToString());
191
192 //Start custom command
193 LaunchCustomCommand(ed);
194 }
195 }
196
197 private static void LaunchCustomCommand(Editor ed)
198 {
199 //Create implied a selection set
200 ed.SetImpliedSelection(new ObjectId[] { _selectedEntId });
201
202 string cmd = _customCmd;
203
204 _customCmd = null;
205 _selectedEntId = ObjectId.Null;
206
207 //Start the custom command which has UsePickSet flag set
208 Application.DocumentManager.MdiActiveDocument.SendStringToExecute(
209 cmd + " ", true, false, true);
210 }
211
212 #endregion
213 }
214 }
This video clip shows the code in action.
If reading the code carefully, one should realize that when "DBLCLKEDIT" is enabled, the custom command only launched when the default double-click command defined in CUI/CUIX is vetoed. That means if there is no default double-click command defined in CUI/CUIX defined for particular entity type, then the DocumentLockModeVetoed event will not fire, hence the custom command will not be launched.
Subscribe to:
Posts (Atom)
Followers
About Me
- Norman Yuan
- After graduating from university, I worked as civil engineer for more than 10 years. It was AutoCAD use that led me to the path of computer programming. Although I now do more generic business software development, such as enterprise system, timesheet, billing, web services..., AutoCAD related programming is always interesting me and I still get AutoCAD programming tasks assigned to me from time to time. So, AutoCAD goes, I go.

