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.

  • John: How would you even monitor every command?

    mdlInput_setMonitorFunction

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  • Hi All,

    Trawling through past posts that mention 'dependency API' 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. See attached zip.

    At the moment, we have the beginnings of pervasive end-user programming (spearheaded by GC, and even Design++?), a lot more dynamic relationships between elements, either in the form of 1/. Graphic to graphic: Dynamic Views, GC symbolic views, XFM,  geometric constraints modeling in PowerCivils 2/. Graphic to non-graphic: To support bi-directional parametric updates between schedules and graphics, hot links between structural design and analysis apps, energy modeling feedback. etc 3/. Non-graphic to non-graphic: ProjectWise dependency tracking, OpenPlant data integration...Promis-E  associated document tracking...

    Managing change propagation is nothing new to coders, but how will end-user programming be integrated into the mix?

    GC's data modeling constructs are being embedded into the dgn. The last standalone version 8.11.8.202 has an interesting dialogue "Parametric Modeling (PM) Settings" that appears to give the user the option to control the propagation / dependencies between elements.  At the moment, if you dimension a GC construct associatively, Mstn bombs when there is a change. Apparently, the shadowy Bentley Interoperability Platform are working on gluing everything together, and the end user programming bits will be able propagate to and from the Bentley bits, in due course.

    MDL-only API: I guess this should change? I wonder how this is going to be implemented across the managed / non-managed code gulf. Will all Mstn elements like associative dimensions, patterns, feature solids etc be re-written as GC features? I guess that the Dependency API would become part of GC's DAG transaction manager? Will there need to be an overarching D-Cubed-style two-pass constraints manager that decides which order the dependency chains are fired, and on which core ? Will Garbage Collection / undo's / transactions need to be updated to cater for data modeling and well as the normal event-based scenario? The whole dotNet reflection, wrappers, Interops, overloading stuff seems like a huge uncharted 'no man's land' where a lot of grown men are on their knees poking the spot in front of them with a bayonet, hoping not to hit a mine.

    Hopefully, Bentley will be more transparent than Revit. Looking at some of the forum discussions, the dependency mechanism is not very well documented and a lot of plugin developers manage their dependencies independently, especially to avoid the dreaded 'regen all'. I hear CATIA is similarly opaque about its dependency management . Maybe things will be simpler with DAG-based tools like Grasshopper (and GC). GH is integrating its SDK into RhinoCommon for V5. GH is also interesting as it licences components from QuantumWhale, which is due incorporate LINQ . Who knows? Maybe T-Splines, RhinoDirect, RhinoParametrics and RhinoBIM will be able to feed off each other and allow the user to modify objects produced by the other plugins without losing their design intent / behaviour. I.e. no return to the old 'zombie' artifact days. Hello synergistic Interoperability.

    I was amazed to find out that LabView is a $600m company. They seem to be a pioneering force as far as integrating end-user programming (using visual programming interfaces, state charts etc) and professional coding, data modeling and even parallel processing. Anyone have experience with LabView? Or MZ-Platform?

     

    Dominic

     

     

     

     

    Dependency-Example.zip
  • National Instruments, Inc

    Dominic: I was amazed to find out that LabView is a $600m company. Anyone have experience with LabView?

    LabVIEW™ is a product — the vendor is National Instruments They've been around for about as long as Bentley Systems. Their speciality is instrumentation control and data acquisition.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

  •  

    Yes.. But, instrumentation control and data acquisition are only one side of what NI does. Check out their development tools based on 'G', a visual dataflow programming language originally developed for the Macintosh as far back as 1986. Apparently, Lego Mindstorms NXT was based on 'G'. NI has developed tools for multiple programming approaches. Modelica is also another programming language / platform that is popular in the simulation world.

    Simulation platforms have been dealing with componentising objects and behaviours, hierarchial models / solvers, multi-domain design, ETO-style port-based modeling, digital mockups, KBE ... etc for a comparatively long time, even before dotNet and Java.

     

     

  • Dominic: But, instrumentation control and data acquisition are...

    Interesting though this conversation may be, it's veered far off the original topic of this thread.

    You may want to post to a more appropriate Forum.

    Regards, Jon Summers
    LA Solutions

     
    Regards, Jon Summers
    LA Solutions

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