Organizing multiple DCL dialogs

Organizing multiple DCL dialogs

hak_vz
Advisor Advisor
3,206 Views
24 Replies
Message 1 of 25

Organizing multiple DCL dialogs

hak_vz
Advisor
Advisor

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.

Miljenko Hatlak

EESignature

Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
0 Likes
3,207 Views
24 Replies
Replies (24)
Message 21 of 25

_gile
Consultant
Consultant

@hak_vz wrote:

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.


This is called a modeless dialog (typically a Palette in AutoCAD) and, AFAIK, simple DCL dialog boxes can only be opened in a modal way.

AutoCAD modeless dialogs called from AutoLISP require a third party application, OpenDCL as said upper or some other (Managed) ObjectARX application.



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

0 Likes
Message 22 of 25

john.uhden
Mentor
Mentor

True, but loading/reloading a dialog is fast, even on this 10-year-old Win7 laptop running 2004.

Plus, if you make a .VLX you can include the DCL in that file.

John F. Uhden

0 Likes
Message 23 of 25

hak_vz
Advisor
Advisor

 


@_gile wrote:


This is called a modeless dialog (typically a Palette in AutoCAD) and, AFAIK, simple DCL dialog boxes can only be opened in a modal way. AutoCAD modeless dialogs called from AutoLISP require a third party application, OpenDCL as said upper or some other (Managed) ObjectARX application.

I was not talking about modal and modal-less dialogs, or maybe I wasn't clear.

 

When one is about to create a dialog he must use (setq dcl_id  (load_dialog dcl_file_name)), test if dialog definition in that file exists, set tile values or what ever is needed, (start_dialog).....(done dialog) and (unload_dialog), what is unnecessary.

 

One can store a dcl definition into a string an create temporary dcl file or use dcl file.  In other words we are all the time connected to some kind of a file since (load_dialog) strictly looks for a file, and issued dcl_id.  It can be a single variable (system parameter) or more, but each one receive a integer value. Problem is that if any of this dcl_ids  stays open i.e  it is not closed by  (done_dialog) your function will crash.

 

At the end I decided not to use single dcl, and try to avoid counting dcl_id values as is shown in 95% examples

(if (>= what_next  2 )........ 

 

As @john.uhden  says, dcl loading is fast, and with modern solid-state drives its just another kind of memory location.

 

Miljenko Hatlak

EESignature

Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
0 Likes
Message 24 of 25

john.uhden
Mentor
Mentor

Anyway, Hak, all the dialogs you use for a program are most probably needed for that program only, so unloading and reloading on the next run you won't even notice.  As I said before, the biggest effort is on your part is to save and repopulate anything you want to be a default value or list for any/all of the tiles.

John F. Uhden

0 Likes
Message 25 of 25

hak_vz
Advisor
Advisor

@john.uhden 

 

I have written my dialog handler that works well. Storing and retrieving dialog tile values is handled through text files while changing particular tile value is handled through a list. List holding dialog values during change is created as list of dotted pairs i.e (key . value). Values are first changed in a list and than storage file is rewritten. For each dialog there is a safety copy to repopulate tile values with its defaults.

 

(defun string_to_list ( str del / pos )
; Author: Lee Mac
    (if (setq pos (vl-string-search del str))
        (cons (substr str 1 pos) (string_to_list (substr str (+ pos 1 (strlen del))) del))
        (list str)
    )
)    
    
    (defun dialog_out(filename keylist / file1)
        (setq file1 (open filename "w"))
            (foreach key keylist
                (setq val (get_tile key))
                (if val
                    (progn
                        (write-line (strcat key " " val) file1)
                    )
                )
            )
        (close file1)
        (princ)
    )
    
    (defun dialog_in (filename / lin key val)
        (setq f (open filename "r"))
            (while (setq lin (read-line f))
                (setq lin (string_to_list lin " "))
                (set_tile (car lin) (cadr lin))
            )
        (close f)
        (princ)
    )
    
    (defun file_to_list (filename / f lin ret)
        (setq f (open filename "r"))
            (while (setq lin (read-line f))
                (setq lin (string_to_list lin " "))
                (setq ret (cons (cons (car lin) (cadr lin)) ret))
            )
        (close f)
        (reverse ret)
    )
    
     (defun list_to_file (lst filename / r)
; saves list of dotted pairs into a file
        (setq f (open filename "w"))
            (foreach el lst
                (write-line (strcat (car el) " " (cdr el)) f)   
; this is since on cons list car retuns first element while cdr rest of dotted pair
            )

        (close f)
    )
    
    (defun replace_list_element (lst key val)
        (setq
            old_item (assoc key lst)
            new_item (cons key val)
            lst (subst new_item old_item  lst)
        )
    )

Miljenko Hatlak

EESignature

Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
0 Likes