Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
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
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Paul Tiplady, on Tuesday, December 16, 2008 3:59 PM

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!
 6-Sep-2007 13:15
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

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
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 15:10
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

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
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 15:20
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

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
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 15:36
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

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
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 17:41
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 19:46
User is offline View Users Profile Print this message


Douglas Zawacki

Posts: 58
Joined: 17-Oct-2006

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.
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 20:26
User is offline View Users Profile Print this message


ron lewis

Posts: 650
Joined: 20-Sep-2004

The attached script indicates 1489 may be close to functional limit.

Edited: 6-Sep-2007 at 20:28 by ron lewis
Report this to a Moderator Report this to a Moderator
 6-Sep-2007 20:36
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

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
Report this to a Moderator Report this to a Moderator
 7-Sep-2007 08:29
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

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:

Originally posted by: Kevin Murphy
Gotta love DXL sometimes.

Sometimes?

Thanks for all the help guys!

Paul.

-------------------------


Paul dot Tiplady at TRW dot com
TRW Automotive
Report this to a Moderator Report this to a Moderator
 7-Sep-2007 13:48
User is offline View Users Profile Print this message


Paul Tiplady

Posts: 176
Joined: 28-Oct-2003

quote:

Originally posted by: Paul Tiplady
I'll pore through the constraints one at a time and check them. What fun!

  • I checked the constraints - no problems spotted, no improvement
  • I made sure I'd got all the constraints in for all DBEs (top, left, right, bottom, in that order) - no change.
  • I added a switch to turn off the placement. The dialogue box ended up way too long to fit on a screen, (as you'd expect), but still no improvement.
  • I swapped out the standard 'Close' button for a custom one - I can now close the dialogue, but otherwise there's no change.
  • The crash occurs on either a 'realize' or a 'show', which still seems to point at something in the set-up.
  • I tried running the thing on a virgin module - the problem goes away! Now we're getting somewhere...

    Maybe someone can comment on the following:
      I'm setting up an array right at the top of my code, by counting all the enumerated type, object level attributes from the current module, then declaring a string array of the appropriate size, then populating this array with the names of the attributes. This array is then used to initialise several DBEs of type choice. Can anyone see a problem with that? (Code attached, in case anyone wants it...)

      I'm unclear on whether I can reset the content of a choice DBE after it's been declared but before the DB is shown. Currently I only update DBEs when the tab changes, and the 'front' tab is static. so I don't need to update in this time. Is my assumption good? Did I miss a trick?

    Still struggling...

    -------------------------


    Paul dot Tiplady at TRW dot com
    TRW Automotive

    Edited: 7-Sep-2007 at 13:50 by Paul Tiplady
  • Report this to a Moderator Report this to a Moderator
     7-Sep-2007 14:49
    User is offline View Users Profile Print this message


    Kevin Murphy

    Posts: 206
    Joined: 15-Jul-2005

    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
    Report this to a Moderator Report this to a Moderator
     7-Sep-2007 20:02
    User is offline View Users Profile Print this message


    Louie Landale

    Posts: 2070
    Joined: 12-Sep-2002

    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.
    Report this to a Moderator Report this to a Moderator
     10-Sep-2007 14:42
    User is offline View Users Profile Print this message


    Reik Schroeder

    Posts: 361
    Joined: 28-Jul-2003

    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
    Report this to a Moderator Report this to a Moderator
     11-Sep-2007 17:20
    User is offline View Users Profile Print this message


    Chris Jones

    Posts: 177
    Joined: 1-Jul-2005

    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
    Report this to a Moderator Report this to a Moderator
     24-Sep-2007 12:57
    User is offline View Users Profile Print this message


    Frank Jensen

    Posts: 24
    Joined: 18-Sep-2007

    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
    Report this to a Moderator Report this to a Moderator
     24-Sep-2007 14:23
    User is offline View Users Profile Print this message


    Tony Goodman

    Posts: 1098
    Joined: 12-Sep-2002

    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
    Report this to a Moderator Report this to a Moderator
     16-Dec-2008 15:59
    User is offline View Users Profile Print this message


    Paul Tiplady

    Posts: 176
    Joined: 28-Oct-2003

    Answer 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!

    -------------------------


    Paul dot Tiplady at TRW dot com
    TRW Automotive
    Report this to a Moderator Report this to a Moderator
    Statistics
    20925 users are registered to the Telelogic DOORS forum.
    There are currently 2 users logged in.
    The most users ever online was 15 on 15-Jan-2009 at 16:36.
    There are currently 0 guests browsing this forum, which makes a total of 2 users using this forum.
    You have posted 0 messages to this forum. 0 overall.

    FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.