EDGCNTRL / EDGPACKET / EDGPICKPACKET / EDGPOSITIONDATA

I am trying to get the position of a single picked point through the edgcntrl command

It's not so clear for me and seems complex and also the fact that it continues with the code and doesn't pause like the pick command. Maybe there is a workaround for the last comment.

In it's most basic form :

!packet             = object EDGPACKET()
!packet.action  = 'put command here to find postion picked'
!!edgCntrl.add(!packet)

How do I extract the position of the pick ? I see many programs putting this syntax in : !this.return[1]

How do i halt the program while I pick something ?

If the program can't be halted, the above syntax can only ever be at the end of a program. Doesn't seem right. I am definitely missing something.

  • It is all described in Software Customisation Reference Manua - Event Driven Graphics

    But basically, you define your edgPacket and then hand it over to the edgCntrl (=Event control system), which, t will call the action-callback you defined in the packet after the picking is completed. Thus you "cannot" use edgPacket in a "run-all-lines-to-end" macro-style,

    Using pick command

    form.MethodA()
    
    var !p pick
    
    !!ce.position = !p[1].dbref().position
    
    endmethod

    Using edgPacket

    form.MethodA()
    !packet             = object EDGPACKET()
    
    !packet.action  = '!!form.MethodB(!this.return[1])
    !!edgCntrl.add(!packet)
    endmethod
    form.MethoB(!posData is EDGEPOSITIONDATA)
    !!ce.position = !posData.position
    endmethod

    Or something like that :)

  • Hi. Thanks for that.
    I will have a better look shortly

  • Thanks

    "Thus you "cannot" use edgPacket in a "run-all-lines-to-end" macro-style

    Which is how I want to use it. Damn. The pick command has limited functionality but in most cases has what i require, but lacks a graphics pick. It does element and pline.

  • Why do you want to use macro-styles stuff instead of say Forms and Objects?

  • Mostly the fact that I move around from place to place and some may not allow me to put my files amongst theirs for the rehash all.  ALso some companies have very complex setups, with some running batch files to copy files from servers to local drives and the files there get overwritten. etc etc etc So while not ideal, I manage for the most part to achieve what I require. Would be nice if you could just set the support paths easily from within E3D, like Autocad under options. Works great with the ultimate flexibility. Anyone can easily use their own programs from wherever they like.

  • I use forms a lot, when I need to. Only thing is, I can't use functions and methods as it doesn't recognise them. I end up with more files than normal, but it works ok. 

  • I'm in the same boat as you, I have a macro system that doesn't rely on PML locations for the same reason. I'm very interested in this topic and it will be very helpful to know if there is a way and what it is. Many thanks in advance

  • It's a bit frustrating the way Aveva have set up the pml system. What's with the rehash all ? WHy not simply have path options within design / draft that can be added to and altered. Not very flexible as it is.
    However I manage to get most of what I want working

    I'm quite sure we're not the only ones that have this same issue and have been forgotten about. Not everyone that programs within PDMS / E3D is part of the company admin team, but still want to run their own programs.

    What is it that you want to know ? Maybe I can help you.

  • If you want to avoid having to rehash the pml.index,
    You can copy and modify the launcher init files that and modify the PMLLIB environment variable.
    You can also ask the company admin to give you a E3D modified launcher for this.

    On the original PMLLIB value, add another folder on the leftmost part which points to a folder your local computer.

    This will create a new PMLLIB folder where you can put your own programs.
    A new pml.index file will be created here which will list your own programs and also the company's existing programs from the original PMLLIB folder

  • The reason for these restrictions is because we have to prevent users from running untested code in production/live projects. I know it is frustrating but this is the job of the company admin.