![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Replace Save Module Confirmation on 'X' Click. Topic Summary: Created On: 23-Aug-2007 14:16 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Triggers in a nut shell: 'pre' triggers occur before the event and 'post' triggers occur after. A post-module-close trigger will disallow access to the open 'Module' since its already after the close (the event). Pre-triggers allow the coder the option to prevent the event. That is, a pre-close-module trigger can be written to stop the module from closing; such as if the user made changes but failed to add to the Comments attribute. set(trigPreConFail) and set(trigPreConPass) are the mechanisms for the trigger ..err.. the pre-trigger to deny or allow the event. If you set(trigPreConFail) in a pre-module-close trigger then the module will not close. I'm pretty sure that if you have several pre-module-close triggers, that if ANY of them set(trigPreConFail) then the module won't close; I don't think the last trigger has the final say. I wonder if the lower-priority triggers even fire if the first higher priority trigger has denied closing. I also believe that set(trigPreConPass) isn't really needed, except if you've already issued set(trigPreConFail) and then changed your mind. These commands set a pass-fail flag which is used later; you can change your mind as often as you want in the trigger and the last one issued is the one used for that trigger. (I'm saying they do NOT behave like a 'return' command, which ends processing right there). These commands are benign in post-triggers. - Louie | |||
![]() |
|||
Here's strange one. I need to run a script any time a module is saved. Common sense would tell you trigger, but you can't run a trigger on a module save, at least according to the documentation. So, I can easily replace the calls in the save menu and button, and even disable the Ctrl+S. Now my issue is when a user attempts to close the module prior to saving. The menu option on the file menu I can replace easy enough, however, my issue comes if the user presses the "X" button in the upper right hand corner. Now I have set up a trigger, to run on a module close that "replaces" the Save confirmation box (see attached), however as soon as the user clicks any of the buttons, the built in confirmation box appears. Hence you see the same box twice, not to mention it hides the dialog box that appears from my script if you press "Yes".
Anyone know if there is a way to disable this, so that I can run my version instead?
------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com Edited: 23-Aug-2007 at 14:17 by Scott Boisvert |
|||
![]() |
|||
![]() |
|||
Hi Scott,
did you tried to implement the functionality of closing with or w/o saving yourself? You should use save (Module) and close (Module, bool, bool). When you close the module with close (Module, false, false) no message appears and the changes will be discarded. Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|||
![]() |
|||
![]() |
|||
I think Scott is talking about when the user clicks on the 'X' and changes have been made to the module. So he hasn't done the save(Module) first.
Hate to reply and be of no help, but I'm not sure what you're wanting to do is easily done. That's why my rule of thumb is to not customize DOORS too much--you run into corners like this and then have no way out. It's just easier to tell the users that something can't be done. I do hope you find a solution, and if you do, post it here. ![]() ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|||
![]() |
|||
![]() |
|||
quote: Yeah, what he said. I know I can close the module with out getting the dialog box easy enough. But I have no way of getting around it when the "X" button is clicked even if I save the module in the script that is called. Once any of the buttons are clicked on my dialog, DOORS is no longer blocked by my script and displays it's own dialog. I want to disable the DOORS dialog...... Yeah, see the problem is, I'm dealing with 200+ engineers that don't listen......lol We've gone down the road of, "Please do not do xxxxxx....", some of them listen and abide but others never even read the e-mail. I'm still getting phone calls and e-mails about stuff I sent out 9 months ago...lol. I gotta treat my engineers and developers like children and restrict them from doing what we don't want them to do. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|||
![]() |
|||
![]() |
|||
Hi Kevin, Hi Scott,
for clarification, I thought about an pre close trigger which fires before save dialog box appears, so you could save or discard yourself. Additionally you may use result condition (set trigPreConFail / set trigPreConPass) to (dis)allow closing of module in this way ![]() The only thing I'm not sure about, is if you can create an endless loop in this way, because the call of close function may fire the trigger again?! Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|||
![]() |
|||
![]() |
|||
quote: Aye, I currently have a pre close trigger, which brings up my version of the save confirmation box before the DOORS one fires however, as soon as you click one of the button, the DOORS one fires off. Kinda defeats the purpose. I'm not sure I understand the set trigPreConFail / set trigPreConPass. The documentation on these aren't that great, which is not unusual for DOORS.....Is this something I would put in the trigger itself or in the script that the trigger calls? ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|||
![]() |
|||
![]() |
|||
Triggers in a nut shell: 'pre' triggers occur before the event and 'post' triggers occur after. A post-module-close trigger will disallow access to the open 'Module' since its already after the close (the event). Pre-triggers allow the coder the option to prevent the event. That is, a pre-close-module trigger can be written to stop the module from closing; such as if the user made changes but failed to add to the Comments attribute.
set(trigPreConFail) and set(trigPreConPass) are the mechanisms for the trigger ..err.. the pre-trigger to deny or allow the event. If you set(trigPreConFail) in a pre-module-close trigger then the module will not close. I'm pretty sure that if you have several pre-module-close triggers, that if ANY of them set(trigPreConFail) then the module won't close; I don't think the last trigger has the final say. I wonder if the lower-priority triggers even fire if the first higher priority trigger has denied closing. I also believe that set(trigPreConPass) isn't really needed, except if you've already issued set(trigPreConFail) and then changed your mind. These commands set a pass-fail flag which is used later; you can change your mind as often as you want in the trigger and the last one issued is the one used for that trigger. (I'm saying they do NOT behave like a 'return' command, which ends processing right there). These commands are benign in post-triggers. - Louie |
|||
![]() |
|||
![]() |
|||
Scott,
You sound as though you are trying to override the "void save(Module)" command something that I also wish to do on a database wide level. Not sure how to achieve this though. My initial thought was to try and overload the save command in the startup file using the "addr_" technique popularized by Mr Schroeder - couldn't get it to work though and wasn't sure about the context - my thinking is a little wooly on this which worries me. Not sure I fully understand the implications and/or possibility of doing this even if it did work and I need to be before using it on the real databases - especially as the API manual warns you to be very careful, perhaps someone out there can enlighten me on a more suitable technique. It is of course possible to trigger something to happen on a save as the DOORS integration with Change Synergy does this so my other thought was to try and use their mechanism - unfortunately some of the code is encrypted - all though that which isn't is very intriguing - and I think that they have also changed the workings of DOORS to make the integration work - perhaps there is an undocumented command/ trigger that could be used or maybe they have extended the api to do it. Interesting subject, but a good way to spend an afternoon getting no where!! ------------------------- Regards, Richard Good |
|||
![]() |
|||
![]() |
|||
Could you point me to some of this information on the "addr_" technique?
Also how do you modify menus like the "File" menu? I know you can add things to certain menus but I was under the impression that the code for the essential menus was encrypted. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|||
![]() |
|||
![]() |
|||
Menu's aren't encrypted,
Depending on which file menu you are looking at, depends on which file you need to modify. For the DOORS explorer, you would need to modify the baseWindow.inc file for the module File menu you would modify the formal.dxl file. Both the baseWindow.inc file and formal.dxl are located in C:\Program Files\Telelogic\DOORS_8.1\lib\dxl\config. Using these two files, one can add or modify menus for both the Explorer and Modules. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com Edited: 27-Aug-2007 at 18:06 by Scott Boisvert |
|||
![]() |
|||
![]() |
|||
I think you meant baseWindowMenu.inc. baseWindow.inc is encrypted on my system.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|||
![]() |
|||
![]() |
|||
quote: Aye, that'd be correct....sorry for the flipper failure...Trying to do ten things at once...lol. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|||
![]() |
|||
![]() |
|||
Hi Richard,
it is not possible to override the save function of the native Doors module. The call for saving module information is hardcoded within the formal module implementation, so you have no chance to override anything on this functionality. To do something like that you would need to override the function before compilation of doors.exe ![]() ![]() Unfortunately there are no pre/post save triggers available on module - this may solve your problem too?! BTW: The "addr_" technique is only needed for overriding callback functions because you need to save the original callback. To override existing doors functions you need no "addr_" statements. Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|||
![]() |
|||
![]() |
|||
Hi Reik,
quote: I think you're right, I misunderstood what you were doing with the listview callbacks. One way round this is to have an AutoHotkey script listening for the various ways you can save a module within a DOORS Module window then doing what I want it to do, but this is to easy to get around unless I can manage to install it as an unkillable process or maybe fire the process whenever DOORS is fired there's a solution somwhere but its not an easy/obvious one!! What I am thinking of doing is implementing a powerful but simple change control system entirely within DOORS and using module attributes containing XML, but this needs to be fairly well bolted down and there in lies the problem. We tried Telelogic Change but found the lockdown to severe I am therefore evaluating alternatives involving talking to other change control systems or doing it all in DOORS as you can imagine there are several large problems to overcome - this being only one of them, the mindmap is now about 10 A3 pages and growing!! ------------------------- Regards, Richard Good |
|||
![]() |
|||
![]() |
|||
Hi Richard,
to achive the correct filling of some attributes you could use attribute pre save triggers?! They could check the attribute value against your defined rules and disallow the user to change it to incorrect values. Another option is to use object sync and module close trigger to recognize the changes and process them. I've implemnted a logger script in that way. Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|||
![]() |
|||
![]() |
|||
Hi Reik,
quote: Yes I know that and use this technique elsewhere, but I'm trying to do something far more ambitious than that here. I anticipate doing rather a lot of operations on a save and believe trying to do this on an attribute trigger would be far to slow. A close trigger was also a consideration, but this allows the user to save a module then crash out essentially getting round the system and I can't allow the proposed change control system to get out of whack with the module. I prefer attribute triggers to synch triggers as I only want to lock certain user specified attributes, I have considered using these with a close trigger, maybe writing a flag on an attribute change to indicate invalid change which I'd only set to false on a successful close trigger event, I'd then roll back the history in case of the save and crash scenario. I expect I can dream up something workable, but there is no really good solution without a module save event. Thanks for your input. ------------------------- Regards, Richard Good |
|||
![]() |
|||
![]() |
|||
Meant to update this a while ago and forgot. I was able to "override" the default save function by using the set (trigPreConFail) within my trigger. This causes the DOORS native trigger to not fire and lets my trigger script run its course.
Thanks, Louie. ------------------------- Scott Boisvert Engineering Tools Administrator L-3 Communications - Avionics Systems scott.boisvert@l-3com.com |
|||
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.