Organizing multiple DCL dialogs

[hak_vz]

My participation in this forum is mostly orientated towards solving autolisp problems by writing code or  giving advice. I'm now in a situation to ask for advice or eventually piece of well tested code to solve parts of my problem.

I don't expect solution to this in one function, since this would actually present a small GUI handler.

What I would like to here are "word or two" that summarize your suggestions and point to potential traps.

I'm about to finalize creation of one large DCL script that consist of multiple dialogs. All dialogs are stored inside one DCL file that would open at start of working session, and closed when drawing, or Acad is closed, without consecutive reloading at each function start.

There is  one starting dialog from which other child dialogs are called. After selecting child dialog to be opened by pressing a button on base dialog, this dialog should be closed (eventually hidden until the managing function ends),  and child dialog open above. Children dialogs should enable user to select one or more elements from a model space, and perform that  action once or multiple times if needed. After actions performed at particular child dialog are finished, either base dialog is shown or better function quits and user restarts the process. During each session, and in next session when function start again, elements on child dialog (if that child dialog has been used before), should preferably retain last entered values and its position.  A cherry on top of a cake would be option to store this data into some kind of a template, that loads next time when app is started. 

I know how to create most of the stuff, but I'm not so versatile with using reactors. As I stated before, I would love to here your suggestions about solving this problem, and how to approach it.

Issues that interest me most:

• how to organize start_dialog and done_dialog to enable hiding dialogs
• potential inclusion of vl-reactors if it really brings overall improvement (or it can be a trap) 
• changes in DCL after version 2014 that may be of interest.

Important notice:

I'm not asking you to write down a code, I will do it myself. Only if you have well proved code, (except some short snippets) then attach it as a file to your post, without pasting into a text editor. 

Thank you all!

P. S.

I won't answer to each post in next few days (only if necessary) to enable better readability since there are probably other users interested in this subject.

[Sea-Haven]

There is a problem that you have to close dialouges to pick objects then reopen so with child dialouges may need some smart programming to return to that child. I use child but only for dcl input so sorry no suggestions.

Maybe Opendcl can help it has a forum start there. 

Also https://autolisp-exchange.com/ there is a get point dcl example.

[martti.halminen]

I try to avoid working with DCL when possible, so I can't help on your specific question, but one general observation: I've seen some examples where people  write large parts of the logic in action_tile calls inside the parameter string, causing all kind of complications with escaping quotation marks etc. It is much easier to just call a simple Lisp function, doing all the complicated stuff inside that function as strictly lisp, without fighting with DCL.

[doaiena]

Is OpenDCL an option for you, or you must stick to DCL?

[diagodose2009]

My application parse-(tokenize) all files.Dcl form zip and he inject the file.Dcl inside autoLisp-source-inside each function.

Please you see the "cdate.gif"

You check "t025_acad_98256.txt" inside archive.

You can test the app.lsp with Q2[enter]

[hak_vz]

I really like your code.

[hak_vz]

@doaiena @Sea-Haven  One of options was to use OpenDCL but I haven't used it a lot, simple DCL was better for me. OpenDCL is dependent on other technologies and run-times  that have to be updated or changed from time to time, and I can not leave that to inexperienced user.

What I really miss from OpenDCL is a GUI for designing and classic textual DCL file, but I haven't seen this in ACAD programmers agenda from the time DCL was introduced. Please count this as an Idea, if autolisp is there to stay. 

All this fuss is actually a result of how Windows GUI works.

I think I have figure out the best option and that is: treat each dialog as a separate entity, before you jump to another dialog  close active dialog. If you need to show an hide one dialog more then once, collect all values from dialog tiles and close it. When you have to show it  next time, repopulate dialog tiles with values stored in what ever way you like it.

Action flow from a selected tile (let say a button) should only return value to calling function, eventually issued done_dialog if needed, but then in governing function you have to test if dcl_id is still active. Dcl_id should be localized for any function that opens a dialog. 

  @martti.halminen  I agree with you about avoiding DCL when ever possible, but this time I need it achieve  simplified user system interaction. What I also hate is entering wrong value in a console based function, and iterative "are you sure" queries. 

[doaiena]

I asked about OpenDCL, because i have a lot of experience with it and could provide help if needed. I avoid using DCL, mainly because it's a pain to create complicated dialogs and there is a lot of functionality missing, that ODCL provides.

I've never tested it but, if you need to automatically open and close parent/child dialogs, you could probably create some sort of stack, where you store the dialogs and their settings. Then have a reactor to monitor if there is a dialog in the stack, waiting to be opened. I would have to test that if it works at all.

[hak_vz]

How much fuss is when user who knows nothing about setting and updating OpenDCL have to apply changes? And how it works in network?

[doaiena]

You need to load the ODCL runtime in AutoCAD. It is an .arx file, which can be automatically loaded via lisp. Each version of ACAD has its respective .arx file.

(cond
((= "20" (substr (getvar "acadver") 1 2)) (vl-arx-import "odcl20.arx"))
((= "21" (substr (getvar "acadver") 1 2)) (vl-arx-import "odcl21.arx"))
;and so on...
)

I haven't loaded .arx files over the network, but i don't think it will be a problem.

In addition to the runtime .arx file, you would need to supply the file, containing the dialogs (same as the regular DCL).

[hak_vz]

And when new acad version comes out it is only a matter of downloading and uploading OpenDCL Studio? I don't want to impose an obligation to users to install additional software.

[doaiena]

ODCL Studio is a GUI only used to create dialogs. The user does not need to install anything, they just need the odcl runtime file for their version of acad. You are the one that has to use the Studio to create your dialogs there. I have dialogs that were created with an old version of studio (6 or 7, im not sure exactly) and they still work with the latest runtime without a problem.

[hak_vz]

Thanks @doaiena  I'll try to play for a day or two with DCL, and if there will be too much problems, I'll switch to OpenDCL

[john.uhden]

I've done it before.  My largest utility, called LABEL_IT, has several different dialogs that pop up based on the user's pick in another, or even from a keyword.  Thanks to using (grread) for most inputs and cancels, its complexity is too much to display here.  Give me some time to take a look at it and see if I can extract a synopsis.  I know that I used only one DCL file.

[hak_vz]

---

@john.uhden wrote:

Give me some time to take a look at it and see if I can extract a synopsis.  I know that I used only one DCL file.

---

I would really like to hear your experiences with DCL, but it is not a hurry. Easter is here and I won't do any programming in a next few days.

[Sea-Haven]

Like John I have a dcl that pops child dcl over parent as an example the "wall size" has 3 entry with each having a slider set at 10mm incs or enter a value and the total displayed at bottom, is this what you want like John its multiple dcl in one file.

[hak_vz]

---

@Sea-Haven wrote:

Like John I have a dcl that pops child dcl over parent as an example the "wall size" has 3 entry with each having a slider set at 10mm incs or enter a value and the total displayed at bottom, is this what you want like John its multiple dcl in one file.

What I actually need is to close a parent dialog and than open a new one depending on action selected in first dialog.

I have achieved that the way I described in previous post, by catching action from a pressed button in first dialog, closing him and than starting opening a new dialog. That way I break parent child relation. If I would have a situation as you have with dialog over dialog it would be much complicated to return back and forth from dialog to application, and closing a parent dialog when child is open would cause a glitch.

Each button press at first (parent) dialog issues a (done_dialog) to close it after button is pressed. Structure of a lisp function is something like:

(defun create_dialog ( / dcl_id action _set_action_and_close_parent)	
    (defun  _set_action_and_close_parent ()
     (setq action "new_action")
     (done_dialog dcl_id)
     )


    (setq dcl_id (load_dialog dcl_file))
    (if (not (new_dialog "dialog_id" dcl_id))
        (exit)
        (progn
            (action_tile "some_tile" 
                     "( _set_action_and_close_parent)"
             ) ; to avoid string escape error
            (start_dialog)
            (cond ((and dcl_id)(done_dialog dcl_id)))    
        )
    )
    (if (and action)(create_child_dialog  action))
    (princ)
)
    
(defun create_child_dialog (action)
    (cond
        ((= action what_ever)(start_new_dialog))
    )
)

[john.uhden]

My LABEL_IT doesn't employ "child" dialogues.

Within one DCL file you can create numerous dialogues, e.g.

First {dialog

  blah

  blah

}

Second {dialog

  blah

  blah

}

etc.

Your code just closes one and opens another.

The only annoying thing is naming all your symbols uniquely so you can repopulate a previous dialog.  With LABEL_IT I had to use different prefixes for symbol names to identify which were defaults (read from a file) and which were overrides.  Of course the default file was overwritten with the latest preferences, including overrides, upon exit.

[hak_vz]

After some testing I have decided to follow that path. I will use a child dialogs where possible, but generally I'll follow this open -> change -> close -> repopulate cycle. Values are stored in an output file. 

[john.uhden]

Yay! I'm sure you will handle it well.
Do you do any bearing and distance labeling? My LABEL_IT program is really
great with lots of options you can change on the fly. I am thinking of
being beneficent plus demonstrating how the dialogs flow.