Tracking element changes - as they happen?

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.

Parents Reply
  • Dependency API

    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.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

Children
  • 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 …

    • Tags
    • Dimensions
    • Associative Patterning

    History

    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.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • 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...Geeked

    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.

  • 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



  • Dependency != Parametrics

    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.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • 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.

    John.

  • 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?

    John

  • 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

  • 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 …

    MicroStation V8i

    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.

    MicroStation V8.5

    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.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  •  

    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:

    • register global input monitor
    • handle all changes on dgnBuf
    • or if you are not familiar with global input monitoring
    • if incomming command is modifier, save dgnBuf state and wait for input
    • if input begins with datapoint, start view motion callback (monitores same cursor moves as dynamics)
    • get element from dgnBuf and if it is different from saved state modify all another dependent elements
    • for mouse position in world coordinates use mdlSystem_getCursorPosition and correct transform
    • on each another datapoint check dgnBuf state, still global input monitor lets you know all needed

    Dan