Hello all - I am currently trying to write a dxl script that would allow me to find the last object curernt displayed on the screen. I am flat out of ideas at this point and need some help! any thoughts?
Porter
Porter - Mon Jun 27 14:40:38 EDT 2011 |
|
Re: finding the last object on the screen OurGuest - Tue Jun 28 07:08:31 EDT 2011
Porter, Look at function: isLastObjectInDXLSet(Object)
|
|
Re: finding the last object on the screen Porter - Tue Jun 28 11:37:13 EDT 2011 OurGuest - Tue Jun 28 07:08:31 EDT 2011
Porter, Look at function: isLastObjectInDXLSet(Object)
I have looked at that function, however when not using layout DXL every object returns true.
Porter
|
|
Re: finding the last object on the screen Mathias Mamsch - Tue Jun 28 15:01:57 EDT 2011 Porter - Tue Jun 28 11:37:13 EDT 2011
I have looked at that function, however when not using layout DXL every object returns true.
Porter
Hmm ... I guess you could trick something, where you insert a DXL layout column and somehow grab the result, but the question would be, why would you want to do something like that? I think you might be out of luck when it comes to the builtin perms... Maybe you can get a similar user experience by a completely different method that does not require to determine the display set? Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: finding the last object on the screen llandale - Tue Jun 28 16:16:07 EDT 2011
Do you mean the last one displayed in the module? Does not change as you scroll.
Object o = null
for o in (current Module) do {}
print (identifier(o)) " is last\n"
Digressing: that's one of the rare times you'd use the "for o in m do" loop, instead of the display independant "for o in entire m loop".
Do you mean the last one displayed currently in the module window? Does indeed change as you scroll.
Don't know. If this is what you mean then I'm VERY curious why you would care.
|
|
Re: finding the last object on the screen Porter - Tue Jun 28 16:34:54 EDT 2011
Louie - I am interested because I am working with some DXL attributes that pull information from other modules based on the link(s) in an object. when the refresh DXL attribute command is selected from the drop down it cause each of the DXL attributes for each of the objects to open then close the linked modules. I had hope to expedite the process by keeping modules open until the last object was reached then close them all, I have code that forces the recalculation for each attribute and when i get to the last object in the module it is easy but if every object is not displayed or does not have values accessed there is no recalculation.
Porter
|
|
Re: finding the last object on the screen llandale - Tue Jun 28 17:55:40 EDT 2011 Porter - Tue Jun 28 16:34:54 EDT 2011
Louie - I am interested because I am working with some DXL attributes that pull information from other modules based on the link(s) in an object. when the refresh DXL attribute command is selected from the drop down it cause each of the DXL attributes for each of the objects to open then close the linked modules. I had hope to expedite the process by keeping modules open until the last object was reached then close them all, I have code that forces the recalculation for each attribute and when i get to the last object in the module it is easy but if every object is not displayed or does not have values accessed there is no recalculation.
Porter
Gads, I hate it when I start thinking. I had already wrote a "Don't go there" response, and right before Posting ... here we go.
Your Attr-DXL can force module-context on itself. When run (for the top object in the display), it opens the other modules, loops through ALL objects in the current module calculating the result on behalf of that object and sets that sibling object's attr DXL value. Then it closes the linked modules. The next time that attr-DXL is queried (for the 2nd object in the display), the attr-DXL already has a value and therefore its returned and NOT recalculated.
So the first time the attr-DXL is queried there is a long delay, get a cup of coffee, but thereafter its trivial.
Am VERY interested if someone can realistically make that work.
o Modules that are already open are NOT closed at the bottom.
o If you don't know ahead of time which modules are the target of links then you will need to keep track of the ones you actually open, no doubt in a Skip.
o When null results are calculated, don't forget to set the attrDXL to a SPACE instead of NULL; otherwise you will get hopeless thrashing.
Here's some standard start code for attr-DXL:
if (null obj or // Not running in attr-dxl -
level(obj) < 1) // running at module level? -
halt
// v9.2.0.1 bug, cannot set AttrDXL values of a deleted object. Fixed in v9.2.0.2
if ( isDeleted(obj) and
length(doorsInfo(infoVersion)) >=7 and
(doorsInfo(infoVersion))[0:6] == "9.2.0.1") halt
|
|
Re: finding the last object on the screen Mathias Mamsch - Wed Jun 29 05:13:50 EDT 2011 llandale - Tue Jun 28 17:55:40 EDT 2011
Gads, I hate it when I start thinking. I had already wrote a "Don't go there" response, and right before Posting ... here we go.
Your Attr-DXL can force module-context on itself. When run (for the top object in the display), it opens the other modules, loops through ALL objects in the current module calculating the result on behalf of that object and sets that sibling object's attr DXL value. Then it closes the linked modules. The next time that attr-DXL is queried (for the 2nd object in the display), the attr-DXL already has a value and therefore its returned and NOT recalculated.
So the first time the attr-DXL is queried there is a long delay, get a cup of coffee, but thereafter its trivial.
Am VERY interested if someone can realistically make that work.
o Modules that are already open are NOT closed at the bottom.
o If you don't know ahead of time which modules are the target of links then you will need to keep track of the ones you actually open, no doubt in a Skip.
o When null results are calculated, don't forget to set the attrDXL to a SPACE instead of NULL; otherwise you will get hopeless thrashing.
Here's some standard start code for attr-DXL:
if (null obj or // Not running in attr-dxl -
level(obj) < 1) // running at module level? -
halt
// v9.2.0.1 bug, cannot set AttrDXL values of a deleted object. Fixed in v9.2.0.2
if ( isDeleted(obj) and
length(doorsInfo(infoVersion)) >=7 and
(doorsInfo(infoVersion))[0:6] == "9.2.0.1") halt
I did that for a layout DXL ... The problem that you will have to face is that the DXL variable memory is destroyed after each objects attribute DXL calculation so it is extremely hard to pass any information from one attribute DXL calculation to another. One could always use a temporary string storage like a DXL module attribute (as you suggested) or a text file, but for large datasets you will need some clever lookup, so you do not need to parse a huge string for the information you need.
I found a way to deal with this issue, that makes up for a really nice user experience:
I implemented a layout column, which will query an opened GUI for its values, the cached data (Skip of Buffers) stored in the GUI context. The nice thing is, that the GUI can react interactively to user input and can make the Layout DXL show different information depending on the values of the GUI. So it is kind of an 'interactive Layout DXL'. Additionally the GUI can calculate the values for the column using a timer, making it unnecessary for the user to wait until the script is finished ...
In an earlier approach I did a little bit as you suggested, I implemented a layout column, which will store its values on the first call in a skip list, and in subsequent calls read from the skip list. This requires a bad hack to keep the memory of the first DXL layout call alive: I install a disabled dynamic on-close trigger.
If you are interested I can post some code ...
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: finding the last object on the screen Peter_Albert - Wed Jun 29 05:27:14 EDT 2011 Mathias Mamsch - Wed Jun 29 05:13:50 EDT 2011
I did that for a layout DXL ... The problem that you will have to face is that the DXL variable memory is destroyed after each objects attribute DXL calculation so it is extremely hard to pass any information from one attribute DXL calculation to another. One could always use a temporary string storage like a DXL module attribute (as you suggested) or a text file, but for large datasets you will need some clever lookup, so you do not need to parse a huge string for the information you need.
I found a way to deal with this issue, that makes up for a really nice user experience:
I implemented a layout column, which will query an opened GUI for its values, the cached data (Skip of Buffers) stored in the GUI context. The nice thing is, that the GUI can react interactively to user input and can make the Layout DXL show different information depending on the values of the GUI. So it is kind of an 'interactive Layout DXL'. Additionally the GUI can calculate the values for the column using a timer, making it unnecessary for the user to wait until the script is finished ...
In an earlier approach I did a little bit as you suggested, I implemented a layout column, which will store its values on the first call in a skip list, and in subsequent calls read from the skip list. This requires a bad hack to keep the memory of the first DXL layout call alive: I install a disabled dynamic on-close trigger.
If you are interested I can post some code ...
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Hi Mathias,
the 'interactive Layout DXL' indeed sounds very interesting, and I would be curious to see some code. Do you think it would be possible to check, when the view is loaded, whether the GUI exists already, and if not, create it? That would for sure enhance the user experience ...
Regards,
Peter
|
|
Re: finding the last object on the screen Mathias Mamsch - Wed Jun 29 07:31:08 EDT 2011 Peter_Albert - Wed Jun 29 05:27:14 EDT 2011
Hi Mathias,
the 'interactive Layout DXL' indeed sounds very interesting, and I would be curious to see some code. Do you think it would be possible to check, when the view is loaded, whether the GUI exists already, and if not, create it? That would for sure enhance the user experience ...
Regards,
Peter
Yes this is possible. If the GUI is not started, the Column displays a user defined text, e.g. "Please start the ... GUI". I will see that I post some code. Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|