Creating a complex dialog box

I need to create a complicated dialog box and I'm completely stumped and would appreciate any examples or help. 

The purpose is to display a list of users and then be able to assign them to or remove them from specific department lists. For example, from a listView of usernames, add "user A" to the "Quality Control" listView and "user B" to the "Regulatory Affairs listView, and "user C" to the "Software Development" listView.

Ideally, I want to have the "Username" listView running the full height of the dialog box, positioned on the left. Then, I want to have several vertically stacked frames to the right that have each have "Add" and "Remove" buttons and the specific "Department" listView. 

 

-----------------------------------------------------------
USERS      |                            Quality
user A        |   [Add]           |
user B        |  [Remove]   |
user C       |----------------------------------------
user D       |                             Regulatory
user E       |   [Add]           |
user F       |   [Remove]   |
user G      |----------------------------------------
user H      |                             SW Dev.
user I        |   [Add]           |
user J       |   [Remove]   |
user K      |----------------------------------------
user L      |
user M     |
user N     |
...

 


ZenMonkey760 - Thu Aug 08 20:40:33 EDT 2013

Re: Creating a complex dialog box
Pekka_Makinen - Fri Aug 09 06:22:59 EDT 2013

See the examples in the "Constrained placement" section in your DXL Reference Manual (DXL Help).

Re: Creating a complex dialog box
ZenMonkey760 - Fri Aug 09 14:26:11 EDT 2013

Pekka_Makinen - Fri Aug 09 06:22:59 EDT 2013

See the examples in the "Constrained placement" section in your DXL Reference Manual (DXL Help).

I'm less concerned with placement, even thought that's an issue I will have to deal with, it's more making everything work. The dialog box functionality just doesn't make too much sense to me. It's multiple listView's and associated buttons, and getting everything to work. 

Re: Creating a complex dialog box
GothSloth - Tue Aug 13 18:38:39 EDT 2013

Here are a couple examples that should be in you DOORS client install area.

<doors_root>\lib\dxl\example\tab_example.dxl

<doors_root>\lib\dxl\standard\links\link.dxl

To find more do a windows search in the directory <doors_root>\lib\dxl for files that contain "DBE".

Good luck, dialog boxes take some time.

Re: Creating a complex dialog box
llandale - Wed Aug 14 17:04:22 EDT 2013

GothSloth - Tue Aug 13 18:38:39 EDT 2013

Here are a couple examples that should be in you DOORS client install area.

<doors_root>\lib\dxl\example\tab_example.dxl

<doors_root>\lib\dxl\standard\links\link.dxl

To find more do a windows search in the directory <doors_root>\lib\dxl for files that contain "DBE".

Good luck, dialog boxes take some time.

ListViews, BTW, need to be sized when you design the dialog box, but populated with values AFTER to "realize" the box. 

Re: Creating a complex dialog box
JingC - Tue Oct 15 16:12:21 EDT 2013

Does anyone know how to implement this complex box?

I wanna do the similar DB that has Add/Remove buttons in the middle and two ListView box on each side.

Re: Creating a complex dialog box
Mathias Mamsch - Fri Oct 18 06:50:02 EDT 2013

JingC - Tue Oct 15 16:12:21 EDT 2013

Does anyone know how to implement this complex box?

I wanna do the similar DB that has Add/Remove buttons in the middle and two ListView box on each side.

Well what does prevent you from doing such a dialog box? Can you nail down the problem? The code structure in DXL is always pretty much like:

DB dialog       = null
DBE lvUserlist  = null

// repeat that block for as many groups as you like
DBE lvQualityList = null # list view for quality
DBE btAddQuality  = null # add button for quality
DBE btDelQuality  = null # remove button for quality

// ... callback functions ...
void onClickBtAddQuality (DBE x) { /* get user selection, modify stuff */ }
void onClickBtDelQuality (DBE x) { /*
get user selection, modify stuff */ }

// ... do as many callbacks as you like ...

void makeGUI (DB x) {
    // Build your gui here
}

makeGUI (dialog);
show dialog;

So its quite some work, but nothing really complex, when you know how to read selected items, etc. but there are lots of examples for this out there. If your GUI is very dynamic (where click on button A enables list items C which are filtered by condition C, etc.) then it makes sense to operate on some kind of view model, instead of storing all the data inside the GUI itself.

// *** View Model ***
// use some more complex data structures to store your data (i.e. data you do not display)
Skip skMyItems = ...
Array arMyItems = ...

void addQualityUser () {
  
/* modify view model */;   
}


void delQualityUser () {
  
/* modify view model */;   
}


// --- end of view model ---

DB dialog       = null
DBE lvUserlist  = null

// repeat that block for as many groups as you like
DBE lvQualityList = null # list view for quality
DBE btAddQuality  = null # add button for quality
DBE btDelQuality  = null # remove button for quality


// functions for updating the GUI from the viewmodel
void updateView () {
   // read data from your view model and update the GUI
}


// function for updating the viewmodel from the GUI
void readInputs () {
   // read inputs, selections, etc. update viewmodel
}


// ... GUI - callback functions ...
void onClickBtAddQuality (DBE x) {
readInputs (); addQualityUser(); updateView(); }
void onClickBtDelQuality (DBE x) {
  readInputs (); delQualityUser(); updateView(); }

// ... do as many callbacks as you like ...

void makeGUI (DB x) {
    // Build your gui here
}

// fill the view model with data here
// ....

makeGUI (dialog);
realize dialog;


updateView ();

show dialog;

Although this seems like an unnecessary amount of work, it helps to eliminate dependencies between the GUI elements (button A enables list C) and allows you to store the data in a way more suited to your problem (instead of storing it inside the GUI being forced to use the GUI as storage). It also enables you easily remove the GUI from your code and make for example a batch version of your script, because the view model (logic) is completely independent of your GUI. You can also unit test your logic this way, without havint to deal with GUI. For more on this approach google for MVVM (Model View Viewmodel Design). Of course you can always mix the approaches to only use a 'view model' for what you think is necesary.

Hope this helps, regards, Mathias