Program development with dialog box...how to begin?

[LibertyOne]

I came up with an idea for an AutoLisp program this past weekend and am looking for some advice how to correctly build up the program with a dialog box. As far as my AutoLisp programming experience goes, it dates back to the late 90's, with an intensive burst of programming between 2000 and 2006. Since then I haven't really had the time to do any extensive programming. Just little timesaving programs that are mainly for solving an accute problem and are not needed anymore.

 

I'm looking for is some advice from the forum as to start this program with the best possible method. Develop the program with a dialog from the start? Write the program first and design the dialog last? Or write the program to the design of the dialog?

 

I've written one or two dialogs in the past but nothing to the nature of what I need to accomplish with the program I would like to write. The interaction between the user and the dialog should be dynamic, and from what I have seen that has been done here in the past, it should be possible.

 

So what are your thoughts about the development process of the program/dialog? All ideas, thoughts and input is welcome!

[BlackBox]

Generally speaking, as you've not included much information regarding what you want your routine/application to do, I'd suggest that you first write the routine and allow that to dictate the needs from your form(s). Only then can you determine if any limitation(s) exist within the form component, that may dictate a change in your routine.

 

To truly customize the form though, you really *should* learn DCL. However, if like me you do not know how to code DCL (Dialog Language), then you can always save yourself *some* time by using DOSLib's User Interface Functions, as compared to the time needed to learn DCL.

 

Hope this helps!

[LibertyOne]

Thanks for the quick reply RenderMan. With tutorials and code examples I can get through the DCL stuff. I'm leaning more and more towards the fact that the the dialog box must develop with the program because the user needs to interact, but also be lead down the correct path.

 

For the curious ones out there, in a nutshell the program will do the following:

 

- From a dropdown list the user will select a standard parametric part. This part (depending on which one it is) has specific attibutes from which the part can be manufactured.

- In the first run, I'm starting the list with eight different parametric parts. The next version will have 23 different parametric parts. (At this point the question about breaking down the drop down list into two for filtering reasons comes to mind.) The list will grow to over 150 different parametric parts in the future, but the functionality of the dialog still needs to stay simple.

- Being that parametric parts are to be drawn, there are 12 attributes total defining the 23 different parts. The attributes are user defined in a text box and should be checked for wrong content.

- User input is then read and the part ist then drawn in model space in three views. I'm working on the coding to draw each part and these will be subroutines to the main program.

===========

Dynamic dialog

 

I would like the dialog to be dynamic. There should be an image preview of the part when the user selects a certain part from the drop down list. The image will show the attributes of the part to be filled in.

If there are only three attributes for the part, then only these three attributes should be active for user input, the others grayed out.

 

Although I feel the specifics to the program aren't really that important to discuss at the moment, perhaps what I have mentioned may help shed some light on what I'm trying to accomplish.

[LibertyOne]

I managed to get a screen shot of what the basic layout of the dialog should look like.

 

 

I just need to fill the drop down and make some image slides.

[BIGAL]

Dont forget you can have dialouge open up other dialouges so you could have a group say 8 which then opens up another list to pick from gives you 150 choices as above but not in one list. A-C D-F etc the dialouges re L L1 L2 etc can be interactive with sliders of prefixed increments and limit values.

[BIGAL]

Image example options open to more dialouges

[LibertyOne]

Thanks for the input, BIGAL.

I don't know yet if I'll be needing to open up a second dialog but down the road, who knows.

What I do need though, is a way to change the appearence of the attribute section while the dialog box is open. I have twelve places where I can type in sizes, but depending on the part, I don't need all twelve to be active at once.

For example: I want to make a steel plate. In the drop down list I would select "steel plate". I would need to enter the attributes of length, width and thickness. All others should be grayed out.

I want to draw a bolt. In the drop down list I would select "bolt". The only attributes I need here are length and diameter of the bolt. All others should be grayed out.

[irneb]

You can only enable/disable items in DCL's (using the mode_tile function). You can't hide them, also you can't resize at runtime. There's 2 alternative ways: (1) use Bigal's suggestion of opening a sub-dialog, or close the current one and open a different one where the needed tiles are designed differently. Both ways aren't exactly the "best" UI design possible, but if you stick with only DCL - it's all you can do. The DCL language was truly designed for DOS, it's extremely limited in comparison to today's dialogs / forms.

 

If you want a more "dynamic" dialog look at using OpenDCL instead. Or create your dialogs in Visual Studio and use either DotNet / ARX - you might be able to allow lisp to call these, but then since you're doing DotNet/ARX - Why?

[Guest kruuger]

You can only enable/disable items in DCL's (using the mode_tile function). You can't hide them, also you can't resize at runtime. There's 2 alternative ways: (1) use Bigal's suggestion of opening a sub-dialog, or close the current one and open a different one where the needed tiles are designed differently. Both ways aren't exactly the "best" UI design possible, but if you stick with only DCL - it's all you can do. The DCL language was truly designed for DOS, it's extremely limited in comparison to today's dialogs / forms.

 

If you want a more "dynamic" dialog look at using OpenDCL instead. Or create your dialogs in Visual Studio and use either DotNet / ARX - you might be able to allow lisp to call these, but then since you're doing DotNet/ARX - Why?

it is possible to "show/hide" controls but it might be a lot of work with that.

kruuger

[Lee Mac]

Two dialog definitions I take it?

[Guest kruuger]

it is possible to "show/hide" controls but it might be a lot of work with that.

kruuger

hehe. it is only way with DCL

when we group controls it can be easy done.

kruuger

Mvp.dcl

[irneb]

it is possible to "show/hide" controls but it might be a lot of work with that.

kruuger

That's what I was referring to by closing one dialog & opening another (slightly modified). It's the only way in DCL, and (at best) would cause flikkering due to close & open - which might be bad seeing as OP wants it to happen on a listbox change, not (as per your example) on an expand button click.

[alanjt]

it is possible to "show/hide" controls but it might be a lot of work with that.

kruuger

nice ...............

[BIGAL]

Following on the idea of opening a second dialouge you can have say a 1 line, 2 line, 3 line, 4 line, dcl's and so if bolt it opens the 2 line and the prompts will say length and dia, the same 2 line dialouge though sq plate would say length & width. I have done dialouges with multi images and depending on number of images is which dialouge used.

 

It would need maybe a 3 variable list per combination

2 2 Bolt ie 2 pane dialouge 2 = length & Dia "Bolt"

2 3 base ie 2 pane dialouge 3 = length & width "Base"

3 4 cube ie 3 pane dialouge 4 = L W H "Cube"

2 2 Bar ie 2 pane dialouge 2 = length & Dia "Bar"

and so on

[LibertyOne]

@BIGAL

 

for your idea I would have to eventually make a dialog definition for all 100+ parametric parts? I thought with just one dialog and graying out what I don't to be easier.

[irneb]

Another option could be to split the labels of each edit box, so you can give them a separate key and then change their contents.

Test : dialog {
 label = "Test dialog";
 : row {
   : column {
     : row {
       : text {
         key = "fld1_label";
         width = 10;
       }
       : edit_box {
         key = "fld1";
         width = 20;
       }
     }
     : row {
       : text {
         key = "fld2_label";
         width = 10;
       }
       : edit_box {
         key = "fld2";
         width = 20;
       }
     }
   }
   : column {
     : row {
       : text {
         key = "fld3_label";
         width = 10;
       }
       : edit_box {
         key = "fld3";
         width = 20;
       }
     }
     : row {
       : text {
         key = "fld4_label";
         width = 10;
       }
       : edit_box {
         key = "fld4";
         width = 20;
       }
     }
   }
 }
 ok_cancel;
}

Of course there's good and bad points to this as well. A good point is that your dialog is as small as possible, but a bad point is that the user's spacial memory gets screwed - i.e. the field which was the Length, could now become the diameter.

 

And another option could be to generate the DCL file from Lisp - i.e. have a function save the common parts of the DCL, but place the varying parts conditional to the values in some arguments. As example use my lisp attached to convert DCL to a lisp function.

 

Though if the parameters of your items could be extremely many and varies drastically between items, I'd still suggest using OpenDCL and some form of Table structure instead. That way you could create a dialog which works similar to the properties palette.

Dialogs.LSP

[Guest kruuger]

@BIGAL

 

for your idea I would have to eventually make a dialog definition for all 100+ parametric parts? I thought with just one dialog and graying out what I don't to be easier.

grayed edit_box should be good options for you.

see sample

k.

PopTst.lsp

[Lee Mac]

grayed edit_box should be good options for you.

 

I agree, this is the approach I used in a project last year:

 

[LibertyOne]

@kruuger and @Lee Mac

yes - this is the functionality that I'll be trying to implicate. I'll be on vacation/holiday the next couple of weeks, but as soon as I have something written for the dialog plus the lisp code I'll post it looking for feedback!!

[LibertyOne]

I've looked into the structure and the coding of kruuger's example and I understand the coding but does the program always have to rewrite the dialog coding for each entry in the list when I select it? This is where I'm confused. All I really need is for each entry in the popup list to edit the visibility of the text boxes with an action_tile. (if possible) Sort of like what Lee Mac did in his dialog with the radio buttons.