Hi guys,
Is there a means of tracking the changes being made to an element as hey happen? ie, you click on the start point of a line, say, and as you move it, you get notified (cursor position, the element being changed etc).
Is this possible?
I know of the IChangeTrackEvents interface, but I think that only pre/post notifies you of a change event, but not as it happens (dragging etc).
Regards
John.
In MicroStation terminology, you are asking about dynamics events. As the user provides data points and moves the cursor, MicroStation's primitive command state machine provides the information you want.
It looks like you are interested in the VBA events, so I suggest you look at the documentation about IPrimitiveCommandEvents and ILocateCommandEvents. Each provides a _Dynamics event callback.
The IChangeTrackEvents notifies you when an element has been added, modified or deleted. Your interpretation is therefore correct.
It's useful to know, for example, when a shape element has changed. You can measure its area and update a related text or tag element.
Regards, Jon Summers LA Solutions
Hi Jon,
Thanks for the info, however, the Dynamics events interfaces, as far as I understand it, only work for commands YOU intend on implementing. What I want to know is, how can I be notified when an element is being changed, by say, one of Microstations commands, like Move, for example, not one of my commands.
So, if you have a line, and you click on it's start point, then move it around, I want my AddIn to know about it, to track that movement, know what I mean?
AFAIK there's no way to intercept the dynamics event of another MDL task.
Why do you want to do that?
Hmmm, well, I would like to be able to 'connect' element A to element B, so that when element B gets moved or modified, then element A goes along with it, in real time.
Is this possible in MS?
cheers
I think it would be easier to write your own "extended move function" then to monitor every function in MicroStation, that could move an element.
Mit freundlichen Grüßen / Best regards Volker Hüfner
| AB_DATE Engineering Software | ab-date.de |
johnds said: I would like to be able to 'connect' element A to element B, so that when element B gets moved or modified, then element A goes along with it, in real time.
How about to add those connected elements into cell or graphic group?
Dan
How would you even monitor every function?
Yeah, but then the elements would move as a 'whole', and I dont want that.
I also want to allow the user to modify any number of connected elements 'individually', and have the rest of the connected elements 'react' to those changes. See what I mean?
Kinda like what GC does.
John: I would like to be able to 'connect' element A to element B, so that when element B gets moved or modified, then element A goes along with it
That's a different question, the answer to which is the MDL Dependency API. For an example, look at tags. Define a tag set, tag an element, then move that element. The tags move with the host.
You can achieve the same using the MDL Dependency API. Mark Anderson provided an example some years ago called BoxDemo.
Thanks Jon, I will take a look at the Dependency API, and try find this box demo.
Tags are not what I want, but I will see what this Dep API is all about.
Cheers.
John: Tags are not what I want, but I will see what this Dependency API is all about
I haven't suggested that Tags are what you want: I cited tags as an example of the Dependency API in action. Dependencies are used in many areas of MicroStation V8, including but not limited to …
Dominic: it looks like the callback functions were developed for associative elements like dimensions early on, and later revamped for V8, when the Dependency Manager appeared
MicroStation/J had several technologies that grew independently, such as tags & dimensions. Those technologies added a 32-bit association ID to elements so that the relationships could be coordinated. The APIs were fragile because the association ID could inadvertently become lost or duplicated.
Bentley developed the Dependency Manager as part of V8 to provide a uniform approach to managing relationships between elements. V8 also introduced the 64-bit element ID as part of each & every element, not an afterthought as was the association ID.
By publishing the Dependency API Bentley make it possible for developers to use the same logic. However, to judge from the limited number of questions posted about the Dependency API, few developers have ventured along this path.
Jon: I haven't suggested that Tags are what you want: I cited tags as an example of the Dependency API in action.
Jon, I never implied that that is what I thought you were suggesting! I think you need to liven up a little, and stop being so
pedantic. Anyway, before I stray off the original forum topic...
I think I shall veer completely off the Dependency path, and do it all myself, as I had done in Autocad, given it's current limited 'parametric' functionality.
Thanks for all the info so far.
John
As one of the guys who has done some development with the dependencies, I would suggest to use it, as long a you really like to keep things together but as separated elements :). It's the only way to keep your elements from being touched by mistake without your app loaded or informed.
Your best bet for your own relations is to keep an eye at the Element-Id's, but you will be left alone if someone touches the elements in a kind that those Element-Id's are changed.
I've developed my own parametric elements now for over 10 years - in the end I still live with nested cells in combination with user-linkages, XML-fragments and dependencies.
I still use dependencies to prevent my elements, but give up the try to implement a functionality that keeps (nested) named groups after copying them - a feature that I missed. The problems why I gave up, are not the dependencies, but the complexity of managing the nested groups and the number of callbacks that where called when creating all the needed new groups. I even had to manage the updates of 'my' elements, so that they reappear in the correct named group. In the end I even brought that into my cell management and ended up with one nesting possibility more (with some additional complexity to searches through the cell). But as you mentioned you don't want to merge the elements, this is even necc. if someone else should be able to touch them. But exactly then you need to be informed.
You could track all commands and element changes,but sometimes you will only be informed that 'your' element is about to be deleted - can you decide if it is replaced by another one and which one ?
Not an easy stuff, in each case I suggest doing your development in a native code (C++) app, to be not to far from MDL and MicroStationAPI
Michael
John: I think I shall veer completely off the Dependency path given its current limited 'parametric' functionality
If what you want is parametrics, then the Dependency API is a red herring. MicroStation has provided Dimension-Driven-Design (AKA parametrics or DDD) and an API for a long time. The API for DDD is provided by the mdlCons_xxx and mdlVar_xxx interfaces.
Thanks for the info Michael,
It's interesting you say you have developed your own parametric elements for many years, but it seems you have encountered some difficulty in doing so, I suppose to a legacy of a 'progressing' Microstation.
I have already developed a Parametric system for Autocad (well, I was until I got fedup with acad's terrible rendering capabilities and even worse export functionality).
However, all the parametric logic controlling the acad geometry was completely written by me, no use of internals whatsoever.
What I found very usefull, and in fact I could'nt have done without it, is that your acad plugin can tell acad that you want to monitor ALL mouse events, and therefore, whenever an acad entity gets modified (for e.g you drag a handle), you can then intruct all associated geometry to update itself based on whatever parametric constrains you may have attached to it- in real time.
So this happens without having to firstly invoke some 'edit' command of my own creation.
This is all done using the .net api too, so really easy peasy (no offense to c/c++ guys).
Now, it is this functionality which I am trying to emulate in MS, which I hope is possible, otherwise my plugin will have to have it's own 'move' or 'modify' commands where i can use the IPrimitiveComandEvents blah blah interfaces to track 'dynamics' events.
Hehe, oh happy days.
Yeah, youre correct, dependency != parametrics.
What I was hoping, after you suggested looking at the Dep api, was hopefully to leverage whatever functionality it may already have, and build on it.
But it seems that all parameric logic will have to be done by me, which I dont mind doing, I had just thought that there may be a system inplace already that I could make use of.
Thoughts?
johnds said:What I found very usefull, and in fact I could'nt have done without it, is that your acad plugin can tell acad that you want to monitor ALL mouse events, and therefore, whenever an acad entity gets modified (for e.g you drag a handle), you can then intruct all associated geometry to update itself based on whatever parametric constrains you may have attached to it- in real time.
This is also possible in MicroStation, you can set mdlView_setFunction + VIEW_MOTION / VIEW_NOMOTION in combination with mdlSystem_getCursorPosition, mdlInput_waitForMessage or mdlInput_setFunction to know what command is now active and so on...
But why to do it like this if there is dependency API made for it?
Dan: Why to do it like this if there is dependency API made for it?
The Dependency API provide post-change notification that something happened to another element. It doesn't tell that something is happening now, which is what John wants.
[Edit] Take the tag functionality as an example …
Tag an element, then move that host element. The tags move during dynamics. The move command has been enhanced to pick up dependent elements before showing them dynamically.
Tag an element, then move that host element. The tags move only after you've provided a datapoint; they don't move while you move the host element. In developer terminology, they don't update during dynamics events.
Unknown said:Take the tag functionality as an example: tag an element, then move that host element. The tags move only after you've provided a datapoint; they don't move while you move the host element. In developer terminology, they don't update during dynamics events.
OK, so they don't move because dynamics makes a copy of element, so the only way would be somehow monitor changes on dgnBuf and handle them together with all previously suggested stuff...
John:
You can try this:
my parametric application is not like the one you think of, in fact it is a parametric part-builder for complex things (like a whole side of a building), but it has a strong alphanumerical component. Imagine a 3D office inventar, you can build up everything.
At some time we wanted tables and chairs to keep their formation, i.e. when you move them, but on the other hand let each of them be touchable as single element. This is something you can achive with groups (named and unnamed) and the group lock (move single or all), but after copying the whole group the named group is gone (the numbered groups mostly stay).
Meanwhile and after talking to our customers we decided to let this functionality stay as it is and use some other ways of filtering, accessing and grouping objects. There are sometimes different views at the importance of this and that in the view of a developer and a customer :)
For real time changes the dependency API is worthless (as Jon said), but maybe you like to restrict changes to your elements and those you depend on, then it is really a good choice.