XML addon & script location

Home Forums Problems and solutions in GDL GDL add-ons XML addon & script location

Viewing 3 reply threads
  • Author
    Posts
    • #3667
      Michael Herse
      Participant

      Hi All

      I have what is probably a simple question. If I have library parts that are generating their geometry and obtaining parameter values (for scheduling) from the values in stored in an XML file, which script should I be be reading the XML file in.

      The concern is that if I use the parameter script, object’s will not update to changes in the XML until a user opens their settings and presses OK. If I use the master script, and I have a 1000+ of these object, then I may be creating quite a performance problem for any large file (assuming that AC runs the master everytime the object appears in 2D or 3d – not sure if this is actually the case)

      Has anyone been down this path and found one location better than the other, or another alternative?

      Also, a quick question for the gurus at GSHQ. If I change the value of an object’s parameter in a schedule, should this cause the Parameter script to run, or has this been disabled to help schedule speed?

      Any insight would be appreciated.

      Cheers,
      Michael.

    • #3669
      Gergely Fehér
      Keymaster

      Hi,

      Parameter changes from interactive schedule will initiate a paramscript run in the selected object(s).

      The best way of reading an xml file depends on many things:
      – how often the source will change,
      – will it be a part of the library, and loaded together with the objects,
      – and the purpose of using external data…

      You should tell me more about the details, to be able to suggest a solution.

      Gergely Fehér
      Team Leader, Library Team
      GRAPHISOFT SE

    • #3674
      Michael Herse
      Participant

      Hi Gergely. Thanks for the help. Some more info below.

      – and the purpose of using external data…

      The goal is to allow users to create and assign ‘user defined types’ to doors and their sub-elements (frames, leafs, seals, size, vision panels, finishes etc) that impact the 3D model + some other things such as locking, door stops, closer, hinges etc. that will be stored with a door type for scheduling purposes. The external file is used to centrally store the values of the parameters for the user defined types, and push any change to a defined door type of sub-element through the model. Types will be specific to each project. Some project will have 1000+ doors. One of our current projects has about 5000+ doors made up of about 250 different door types, spread across 4 teamwork files, and is the reason why we are investigating this to see if it will provide an efficient way to push change through the projects and standardise door settings for doors that are meant to be the same, but aren’t in the model.

      – how often the source will change

      Not too often I hope. There will be times when the changes are intense, but hopefully that will be limited to only a couple of periods during the life of the project (late DD and Mid CD). Most of the time, I expect people will just be adding new doors and assigning a type to them, or changing individual doors to a particular type.

      – will it be a part of the library, and loaded together with the objects

      I haven’t got that far yet. Ideally the external file will live in the project library, but the projects will be teamworked, so I need to investigate the implications of this further. At the moment, while we are testing & developing things, the XML is hosted on our file server (OSX)

      Cheers,
      Michael.

    • #3676
      Gergely Fehér
      Keymaster

      Hi Michael,

      If the data is not changing too often, I think I would create a macro, which stores the possible value sets and return them to the caller doors/windows with returned parameters. And if there is a need to change the stored data, I would regenerate the macro – maybe I would write a python script to create a macro in xml format from the data source, and then compile the macro with LP_XMLConverter. After that, you can change the macro in the project libraries.
      This solution would be much faster in AC, than always reading xml files in paramscript. Of course, it needs some more work, when there are changes.

      Gergely Fehér
      Team Leader, Library Team
      GRAPHISOFT SE

Viewing 3 reply threads
  • The forum ‘GDL add-ons’ is closed to new topics and replies.