![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Limitations of dialog boxes Topic Summary: Just how many DBEs canone have in a DB? Created On: 6-Sep-2007 13:15 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: It's taken me an age to get to the bottom of this, at least in part because the dialogue box actually worked once you'd shut down the error box, diagostic log box and DXL edit box - making it a nuisance, not a real problem. But I'm there now! It wasn't the number of elements. It wasn't the constrained placement. It was the initial values of the choice DBEs. I'd been trying to initialise one choice DBE with a list of all enumerated attributes in the module, and a second choice DBE with a list of the enumerations of whichever attribute was chosen from the first DBE. Trouble was, I was using an initial value of -1 for the index into the list (to show nothing had been selected yet), to which DOORS takes exception. I've changed the code to detect the initial condition and use a different set of parameters to initialise the DBE now. The code's not pretty, but it works, at least! The reason the code worked on a virgin module was that there were no enumerated attributes, so the bit of code that was failing didn't run. What was particularly frustrating was that the code didn't fail until the DB was realised, and then it didn't report where it failed - at least not in a debuggable fashion. Old and new code attached (for the further education of anyone interested...) Thanks for your efforts and input all that time ago! | |
![]() |
|
I seem to have hit a limit on the number of DBEs in a dialogue box, although the exact number also seems to be related to the module I open. Yes, I'm confused.
I have a DB with seven tabs, each of which contains various choice, label, field, radioBox and toggle elements. When all is present, I get a DOORS semi-crash - DOORS tells me the DXL has halted with a fairly disastrous looking unexpected error. But the DB keeps running - the tabs work, the 'ok' and 'apply' buttons work, only the 'close' button (and the 'X' button top right) stop working. When I comment out sections of the DB (usually a whole tab at a time) it all works normally (except the missing tab, obviously). But how much (or how many tabs) I have to comment out depends on the module from which I'm running the code. I have about 3300 lines of code (not counting includes!) and one DB with 61 DBEs. Anyone else had similar experiences? I intend to register the issue with Telelogic, but maybe there's some hints from you guys and gals about how to get around this kind of thing... ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
Paul,
My gut feeling is that there is no limit, per se, but rather you have a problem with one of the controls. Good luck determining which! I've made DOORS crash on a List and Choice DBEs by passing a bad string...pass an array that is out of bounds into a list and you'll see what I mean. One of your arrays is likely bad, or the way you've passed it into the DBE is bad. Again, good luck. I say do one tab at a time to isolate the problem. Kevin Murphy http://www.baselinesinc.com ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
Thanks for your answer, but it isn't that simple. I've tried the 'one tab at a time' trick, it was one of my first thoughts. But it doesn't matter which tabs I comment out, commenting some out makes it work, while having them all makes it not work. Or to put it another way, all the tabs work perfectly on their own, or in combination with any other two (sometimes three, depending on number of DBEs) tabs, but not all together.
I've been through all the strings, string arrays, indexes and whatnot, and they all work. Like I say, the whole dialogue box (all DBEs) continues to work properly after DOORS says the DXL has halted. The line it halts on is the 'show (theDB)' line, and there is no code after that, so maybe it has halted... Nevertheless, the DBEs, buttons, tabs etc all work perfectly, with the single exception of the 'Close' button. Still confused! Any more ideas? ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
An idea to further troubleshoot...
Are you using the close() command to override the close button? If not, do. If so, put an ack statement and a hide statement in there and see if that makes it responsive. Odd problem, but maybe overriding close will get help see what works. Gotta love DXL sometimes. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
Hi Paul,
I do also not think about an limitation on number of DBEs. A Diagnostic Log on showing the dialog box appears, if you have created a cyclic constraint placement. I've seen this "feature" many times ![]() So try to check, if all placement statements are in an order, from which you could (manually on sheet of paper) place each element by attaching it to the others. Hope that helps to find the problem, Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Paul,
I have a very large dxl program with 100+ DBEs along with 4 tabs. It's hard to believe that the problem is related to some "internal limit" of DBE's. But I too have run accross the dreaded "Cyclic constraint" issue. And believe me that is a tricky one to debug. For me it got down to actually commenting out one or two DBE's at a time until I found the issue. I had the problem of creating Control A then creating Control B, then attempting to constrain Control A relative to Control B. I know that the constrained placement is just a real headache and in some instances it is impossible to layout a dialog box in a certain way. So, I try to do all sorts of tricks with constraints against other controls. Sorry, I can't provide any real helpful advice except "Divide and conquer". Also, sprinkling your code with "acks" may help you understand the point in the code which the Error occurs. You didn't mention if it actually occurs when you realize the dialog box. If you are not sure, try putting an "ack" message just before you realize the dialog box. When you do figure it out, I'm sure a lot of people would be interested in what was the problem. Dialog boxes are just very painful. Good Luck and Good Hunting. |
|
![]() |
|
![]() |
|
The attached script indicates 1489 may be close to functional limit.
Edited: 6-Sep-2007 at 20:28 by ron lewis |
|
![]() |
|
![]() |
|
My latest program has 66 DBEs in one dialog with no problems. As others have said, it is likely a problem with one of your controls, not a limit. Tools like Michael Sutherland's Enhanced Exporter have far more DBEs without issue.
As far as constrained placement goes, yes its a pain the butt. However I do all my dialogs with it, never leaving DXL to figure out how to lay things out. In order to lay things out, it can be difficult. One trick I use has been to use hidden frames to organize things. You can even stack them if needed. This lets me put things where normally I wouldn't be able to. On a big dialog box I typically have 500 lines just of dialog box design code. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Sounds like it might be a constrained placement issue. I started by creating the dialogue box in one single function. Then I re-factored to have one main dialogue box function that calls a function to set up each tab. There's every possibility that I've created some kind of circular placement constraint in there.
As for frames, I'm using one (visible) frame per tab, and anchoring everything for the tab to the associated frame. I fix the size of the box for the tabs, then for each tab I constrain the frame "inside" the tab, and then constrain most of the DBEs "left"->"inside", with the first one "top"->"inside"->theFrame and the rest (mostly) "top"->"spaced"->previousDBE. Some of them are overlaid, depending on a preceding radioBox, pretty much all of them are "right"->"unattached" explicitly, all of them are implicitly unattached at the bottom. Then there's the fixed stuff above the tabs (version, contact etc) and below the tabs (notes and warnings box, buttons). I'll pore through the constraints one at a time and check them. What fun! quote: Sometimes? ![]() Thanks for all the help guys! Paul. ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
|
![]() |
|
quote: ![]() Maybe someone can comment on the following:
Still struggling... ![]() ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive Edited: 7-Sep-2007 at 13:50 by Paul Tiplady |
|
![]() |
|
![]() |
|
I knew this was a problem with arrays.
I think we're closer to helping you solve this. I did some code, and it's funny how this works. I never tried to use the same DBE twice. Check out this quirk--does it do what you'd expect? (It doesn't do what I thought it would). ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
I'm not surprised that you get 2 elements on the Dialog, since the DBE commands ('choice' in this case) create a DBE and return the value; it doesn't initialize the variable and then put it on the dialog. The code would be the same if the first 'choice' didn't return a variable, and looked like:
DB myDB = create("") choice(myDB, "Choice: " choices, 2) Assigning the created element to a DBE variable just lets you deal with it later, either placing or get or set. Its common to not assign element variables to 'label' DBE commands. Try the attached. It shows that the values of choices[] are not consulted when you use it in a 'choice' command, they are used when the dailog is 'realized'. - Louie This all reminds me of some other thread where some DBE was being populated via some array created inside a function. Since the values weren't consulted until the DB was realized and of course you were no longer in that function, the values ended up being garbage since the stack space used by the function had been reallocated. |
|
![]() |
|
![]() |
|
Thank you, Louie, for clarification,
I was running the script awaiting a suprise .... but all things are "normal" ![]() ![]() Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Along similar lines, I had a script once that would crash with a nasty diagnostic log but still show its DB, but only on some machines (we found it on our remote access machine, which uses Windows 2000 Server; most of our desktops run XP). I eventually narrowed it down to being the DB by where the diagnostic log showed exceptions--I don't remember exactly where but it pointed to a GUI problem, with something going out of bounds.
It turned out to be a choice DBE built with a string array that was always sized 100 but only partially filled. For whatever reason, on the 2000 machine it would still try to create the hard-coded size even though most of the elements weren't initialized, and crash. Maybe this is a similar problem? As far as changing the choices after realization, there is a set() command for that (see below). Almost all DBEs (well, a lot of them) can be changed around after creation by using one or another version of set(): void set(DBE choice, string choices[ ] [,int noOfChoices]) Chris |
|
![]() |
|
![]() |
|
I'm not sure if this helps you to sort out your problem, but I recognized that you should check yout indexing.
For example attrVals[0] never gets assigned as valIndex starts with 1 (Line 38, 41). On Line 67 you try to access the value at position 0 as temp1 goes from 0 to xy. Maybe this can help you, cheers, Frank TRW Automotive ------------------------- Frank Jensen TRW Automotive frank.jensenREMOVE_ME@trw.com Edited: 24-Sep-2007 at 12:58 by Frank Jensen |
|
![]() |
|
![]() |
|
The indexing is good, if a little hard to understand.
The following does exactly the same thing but in a different way which I hope is a little easier to follow. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
It's taken me an age to get to the bottom of this, at least in part because the dialogue box actually worked once you'd shut down the error box, diagostic log box and DXL edit box - making it a nuisance, not a real problem. But I'm there now!
It wasn't the number of elements. It wasn't the constrained placement. It was the initial values of the choice DBEs. I'd been trying to initialise one choice DBE with a list of all enumerated attributes in the module, and a second choice DBE with a list of the enumerations of whichever attribute was chosen from the first DBE. Trouble was, I was using an initial value of -1 for the index into the list (to show nothing had been selected yet), to which DOORS takes exception. I've changed the code to detect the initial condition and use a different set of parameters to initialise the DBE now. The code's not pretty, but it works, at least! The reason the code worked on a virgin module was that there were no enumerated attributes, so the bit of code that was failing didn't run. What was particularly frustrating was that the code didn't fail until the DB was realised, and then it didn't report where it failed - at least not in a debuggable fashion. Old and new code attached (for the further education of anyone interested...) Thanks for your efforts and input all that time ago! ------------------------- Paul dot Tiplady at TRW dot com TRW Automotive |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Limitations of dialog boxes
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.