Hello, I've been lurking these forums for a while, and I finally have an issue I cannot seem to resolve, in spite of the wealth of knowledge available here. Here's the background: I am currently using a pre module open trigger (project->all->module->all) that checks whether the user has a set of startup files in the startupFiles folder within their installation directory. This allows me to load all my libraries once-per-session. This method works quite well, but there is one issue that occurs in the following sequence of events: 1) Create a pre module open trigger, such as the following:
trigger("Trigger1", project->all->module->all, pre, open, 5, "print today")
2) Open a module (edit or shareable) and edit an object attribute (e.g. Object Text). 3) Using the menu (or DXL), downgrade the module to read mode. 4) When prompted whether to save the changes, select 'No' to discard the changes. 5) The cursor will now be stuck in a busy state. If you attempt to change the edit mode, the cursor will remain in busy state. If you attempt to re-read the current module, a runtime error will occur and a diagnostic log will be generated. Ex: read(fullName(current Module), true, true) The same behavior occurs in DOORS v8.3 as well as v9.5. Can anyone give the above the try and confirm or deny these findings? If you have any idea how to fix this, I'd greatly appreciate any insight. Regards, Jacob JDMelvin - Wed Jan 22 14:21:23 EST 2014 |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes So it prints today's date in the middle of step 2), but not otherwise? Is the cursor "IN" a busy state, or are the graphics stuck in the busy-state but the cursor works? Don't know about the cursor issue; but IIRC it happened in the past as well. The perms ..err.. functions that downgrade in the menu did not work perfectly way back in v6 days and I stopped using them. Your diagnostic error is probably because the DXL interaction window is opened by the Trigger, but it is NOT associated with the Module. Thus, "current Module" returns null. Try your read(fullName... again, but first from the module window Tools menu >Edit DXL, which will tie the DXL windows to the module. If you are desperate, change your DXL to
That first command may not be necissary (I think trigPreConPass is the default), but it's good form for "pre" triggers to explicitely decide whether the event occurs (in this case whether the module is actually opened). -Louie |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes llandale - Wed Jan 22 15:48:07 EST 2014 So it prints today's date in the middle of step 2), but not otherwise? Is the cursor "IN" a busy state, or are the graphics stuck in the busy-state but the cursor works? Don't know about the cursor issue; but IIRC it happened in the past as well. The perms ..err.. functions that downgrade in the menu did not work perfectly way back in v6 days and I stopped using them. Your diagnostic error is probably because the DXL interaction window is opened by the Trigger, but it is NOT associated with the Module. Thus, "current Module" returns null. Try your read(fullName... again, but first from the module window Tools menu >Edit DXL, which will tie the DXL windows to the module. If you are desperate, change your DXL to
That first command may not be necissary (I think trigPreConPass is the default), but it's good form for "pre" triggers to explicitely decide whether the event occurs (in this case whether the module is actually opened). -Louie Hi Louie, thank you for your response. The thing is, it doesn't matter what code is running through the trigger. You could literally set the DXL parameter to a comment, like the following:
trigger("Trigger1", project->all->module->all, pre, open, 5, "//This is a comment")
The same behavior seems to arise. The graphics are stuck in a busy state for the cursor, which in of itself is not particularly worrisome. However, any tool that attempts to read the module after a downgrade->discard changes will generate the aforementioned runtime error. It can be fixed by simply closing the module and reopening, but if a downgrade occurs through the module explorer menu, it's becomes more of a challenge. Updating the trigger status appears to have no affect on the behavior. There's some strangeness going on that only seems to occur if the user discards changes prior to a downgrade. As far as executing the read command, this was done via the method you described, so there should have already been a current module. It's not really a critical problem, but I'm trying to narrow down whether the problem is a bug, rather than user error. To reproduce my steps (if you have time and are willing), try creating the static trigger above, then follow steps 2 through 5. I realize that triggers can be a bit fussy, but the pre module open trigger seems particularly sensitive. |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes JDMelvin - Wed Jan 22 16:10:54 EST 2014 Hi Louie, thank you for your response. The thing is, it doesn't matter what code is running through the trigger. You could literally set the DXL parameter to a comment, like the following:
trigger("Trigger1", project->all->module->all, pre, open, 5, "//This is a comment")
The same behavior seems to arise. The graphics are stuck in a busy state for the cursor, which in of itself is not particularly worrisome. However, any tool that attempts to read the module after a downgrade->discard changes will generate the aforementioned runtime error. It can be fixed by simply closing the module and reopening, but if a downgrade occurs through the module explorer menu, it's becomes more of a challenge. Updating the trigger status appears to have no affect on the behavior. There's some strangeness going on that only seems to occur if the user discards changes prior to a downgrade. As far as executing the read command, this was done via the method you described, so there should have already been a current module. It's not really a critical problem, but I'm trying to narrow down whether the problem is a bug, rather than user error. To reproduce my steps (if you have time and are willing), try creating the static trigger above, then follow steps 2 through 5. I realize that triggers can be a bit fussy, but the pre module open trigger seems particularly sensitive. Gave it a try, splitting your step 2) into 2a) <open> and 2b) <edit text> When I skip 2b there is no problem. When I re-insert 2b) then yes it appears the cursor is stuck in the busy state; but that is a graphics issue since the cursor still works. It is in that state for DOORS windows only, not other Windows. However step 5): I can open the module with a double click or re-Edit the module with the menu OK. When I run your code "read(fullName(current Module), true, true)" from the DXL window, as expected I get a "null module parameter was passed into argument position 1" error; but no diagnostic log. I notice no problem when I don't edit text and also when I opt to save the module. So yes there seems to be a graphics problem, but I don't know what to tell you about your diagnostic log. Usually that log is associated with some DXL error in the DXL output window; but not this time? -Louie |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes I see the problem with cursor. But as Louie says, it is just a display issue. In fact, what I observe is, after I downgrade the module and the cursor shows busy, if I double click on an object and click out of it, cursor returns to normal state. If the intention of your pre-open trigger is only to ensure your libraries are loaded, I'd rather suggest using -dxl switch so your code runs just once just after starting DOORS. The flip side is, you can't control it centrally as with triggers. But reduces the burden of running trigger with every module open event. |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes SudarshanRao - Fri Jan 24 03:32:04 EST 2014 I see the problem with cursor. But as Louie says, it is just a display issue. In fact, what I observe is, after I downgrade the module and the cursor shows busy, if I double click on an object and click out of it, cursor returns to normal state. If the intention of your pre-open trigger is only to ensure your libraries are loaded, I'd rather suggest using -dxl switch so your code runs just once just after starting DOORS. The flip side is, you can't control it centrally as with triggers. But reduces the burden of running trigger with every module open event. That's interesting. You're right, if you activate an object, the cursor does in fact go away. I was only concerned about this behavior because of the runtime error that is sometimes generated (at least on my end) if you do a read on the current module directly after downgrading and discarding changes. I'll play around with this some more to see if I can resolve this issue based on your inputs. As far as the intention of the trigger, it's actually designed to check whether the user has the startup files installed, then instructs them to exit and relaunch DOORS to ensure the libraries are loaded once-per-session. Since this method applies to all users on our company network (libraries are used for some attributes and various user-accessible tools), a -dxl switch is not very effective, because I would still need a means of deploying the update to the command switches. The method I am using, while imperfect, ensures all new users have their startup files updated (as well as existing users when necessary) without any change to our process or additional overhead on my end. Compared to the amount of time it takes to read each module, running the trigger represents a small fraction of the overall load time, and so the benefits currently outweigh the costs. Louis: Regarding the diagnostic log, the error actually arises in the baseWindowCallback.inc file, which is encrypted, so I have no idea what exactly it's taking issue with. It doesn't seem to matter what the trigger is doing, as long as I perform the steps I've earlier described, but I might be able to find a solution based on SudarshanRao's input. Thanks again for taking the time to look into this.
Regards, |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes JDMelvin - Fri Jan 24 10:01:25 EST 2014 That's interesting. You're right, if you activate an object, the cursor does in fact go away. I was only concerned about this behavior because of the runtime error that is sometimes generated (at least on my end) if you do a read on the current module directly after downgrading and discarding changes. I'll play around with this some more to see if I can resolve this issue based on your inputs. As far as the intention of the trigger, it's actually designed to check whether the user has the startup files installed, then instructs them to exit and relaunch DOORS to ensure the libraries are loaded once-per-session. Since this method applies to all users on our company network (libraries are used for some attributes and various user-accessible tools), a -dxl switch is not very effective, because I would still need a means of deploying the update to the command switches. The method I am using, while imperfect, ensures all new users have their startup files updated (as well as existing users when necessary) without any change to our process or additional overhead on my end. Compared to the amount of time it takes to read each module, running the trigger represents a small fraction of the overall load time, and so the benefits currently outweigh the costs. Louis: Regarding the diagnostic log, the error actually arises in the baseWindowCallback.inc file, which is encrypted, so I have no idea what exactly it's taking issue with. It doesn't seem to matter what the trigger is doing, as long as I perform the steps I've earlier described, but I might be able to find a solution based on SudarshanRao's input. Thanks again for taking the time to look into this.
Regards, If it suits, maybe you could use post open trigger instead.. Thanks, Sudarshan |
Re: Triggers: Pre Module Open Issue when Downgrading and Discarding Changes llandale - Thu Jan 23 11:06:35 EST 2014 Gave it a try, splitting your step 2) into 2a) <open> and 2b) <edit text> When I skip 2b there is no problem. When I re-insert 2b) then yes it appears the cursor is stuck in the busy state; but that is a graphics issue since the cursor still works. It is in that state for DOORS windows only, not other Windows. However step 5): I can open the module with a double click or re-Edit the module with the menu OK. When I run your code "read(fullName(current Module), true, true)" from the DXL window, as expected I get a "null module parameter was passed into argument position 1" error; but no diagnostic log. I notice no problem when I don't edit text and also when I opt to save the module. So yes there seems to be a graphics problem, but I don't know what to tell you about your diagnostic log. Usually that log is associated with some DXL error in the DXL output window; but not this time? -Louie After taking another look at the runtime error / diagnostic log issue, it appears that it's restricted to DOORS v8.3. So apparently this error was fixed in one of the v9.x revisions, though the issue of the cursor remaining in busy state is version-agnostic. I was more concerned about the former issue anyhow. The latter can be resolved using the method described by SudarshanRao (by activating the object), which if I really cared enough, could be emulated in DXL by initializing the in-place editor (such as using the highlightText perm), then changing object focus (by resetting the current object: current = current Object). Thank you again for taking the time to look into my issue. I am happy to report that once we finally move to v9.5 (it's been a long time coming...), that the error is no longer an issue.
Regards, |