Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why does cancel execute action_tile?

5 REPLIES 5
Reply
Message 1 of 6
Anonymous
551 Views, 5 Replies

Why does cancel execute action_tile?

I have a dialog box with several action_tile, OK and Cancel button. It seems like the Cancel button trigger all the action_tile, is this the way AutoLISP is working?
I have some check routines on some action_tile that I do not want to run when I hit the Cancel button. I thought when you hit the Cancel button the dialog terminated without running the action_tiles.
5 REPLIES 5
Message 2 of 6
Anonymous
in reply to: Anonymous

Hi,

There might be something associated with this button. It can be in the LSP
file, under action_tile argument, or it can be in the DCL file, under action
argument. It would be of great help if you can post the files so somebody
can take a look inside to find what's going on...

Constantin

a écrit dans le message de news:
5262973@discussion.autodesk.com...
I have a dialog box with several action_tile, OK and Cancel button. It seems
like the Cancel button trigger all the action_tile, is this the way AutoLISP
is working?
I have some check routines on some action_tile that I do not want to run
when I hit the Cancel button. I thought when you hit the Cancel button the
dialog terminated without running the action_tiles.
Message 3 of 6
Anonymous
in reply to: Anonymous

Here is some of the code. I have ripped out the subroutine that take care of the input of the dialog box and the dcl code. It is the action_tile "ShaftName" that give me some trouble. When the user leave this edit box the program checks if the ShaftName already exist. I want that not to happen if the user hit the Cancel button. I do not understand why the input in the dialog box is executed when you Cancel the operation.
Thanks in advance.

\Freddy
Message 4 of 6
Anonymous
in reply to: Anonymous

Hi klaudiussen,

I can not make your code to run with the DCL and everything, because I am
missing some user defined functions (like check_real and clear_dlg_error)
and because I don't know what are the four arguments that the main function
needs. Therefore it's very hard to find the bug only looking at the code.
However I will try to guess it. Most probably because as you say, when
you hit Cancel, you leave the tile "ShaftName" and then the checking code
triggers again, because it can make no difference if you remove its focus to
do something else or to press Cancel. So let's try a trick. We are going to
set a flag when hitting Cancel and then check if ShaftName belongs to the
associated list only if this flag is not present. So you are going to add to
your code the next statement:

(action_tile "cancel" "(setq cancel_flag T)(done_dialog 0)") [1]

and then modify your code like this:

(action_tile "ShaftName" "(if (not cancel_flag (action_tile_ShaftName
$value))") [2]

and let's hope that this will solve your problem.

In the same time I have a coule of humble advices:

1) I suggest to use some audit for your DCL files.
Although this is not crucial for the functioning
of your code, sometimes it can be of great help
so I suggest to always include the next line of
code in the beginning of your DCL files:

//==================================
dcl_settings : default_dcl_settings { audit_level = 3; } [3]
//==================================

2) You have two buttons that allow the user to do something
on screen while you hide the DCL. Just a reminder that
the three dots you use on your buttons mean that the
button will trigger another dialog box. This is a Windows
standard and the symbol Autodesk used for picking on
screen was >, something like [Pick on screen >].

3) My experience learned me that is much easier to build
a function for each action_tile, named accordingly as
you can see in my exemple bellow. This allows for easier
further developpement, debugging and maintenance. I think
it's more clear and concise and is much easier to flowchart.
Only think about those boring escape backslashes for the
quotes ! This way, you don't need them anymore. So I
suggest that you reorganize your code this way and try
to see afterwards what is going on with your action tiles.
For instance, the next function is called by its corresponding
tile action:

(action_tile "ShaftName" (action_tile_ShaftName $value))") [4]

;===========================================
(defun action_tile_ShaftName (value)

(setq OldShaftName ShaftName)
(setq ShaftName value)

(if
(assoc
ShaftName
(nth (atoi #JBE_ShaftType) SortedShaftNumbers)
)
(progn
(alert
(strcat
ShaftName
" er allerede i bruk!"
"\n\nVennligst benytt et annet navn."
)
)
(setq ShaftName OldShaftName)
(set_tile "ShaftName" ShaftName)
(mode_tile "ShaftName" 2)
)
)
)
;===========================================

Hope this helps and makes sense,

Constantin

a écrit dans le message de news:
5264318@discussion.autodesk.com...
Here is some of the code. I have ripped out the subroutine that take care of
the input of the dialog box and the dcl code. It is the action_tile
"ShaftName" that give me some trouble. When the user leave this edit box the
program checks if the ShaftName already exist. I want that not to happen if
the user hit the Cancel button. I do not understand why the input in the
dialog box is executed when you Cancel the operation.
Thanks in advance.

\Freddy
Message 5 of 6
Anonymous
in reply to: Anonymous

Hi Gherasim and thank you very much for your great help.
First of all, sorry not to reply on your answer before. I have been tied up with something else. I agree in all your comments and I send you a big thanks for all your good advices. Best of all, your suggestion worked just fine.

I have some further question about #3 comment. I wonder where you place your code for each action_tile functions? Inside the function that control the dialog box? As you see I have a lot of variables that I need to bring with me into the function and I want to have as few as possible of global variables to deal with.

\Freddy
Message 6 of 6
Anonymous
in reply to: Anonymous

Hi again,



Don't worry about the delay, I was thinking that you are busy or maybe in
vacation. As for the problem that you had, I am glad that the solution
worked and you are happy.



Talking about #3 comment, I see no problem here and there are no new
variables to deal with. As you can see in the attached file, the new
Action_Tile_TileName functions are defined in the same file where the
action_tile code was originally placed and the variables are the same as in
the original file and at the same place, i.e. in the main function, which is
at the bottom of the file. Even though they are global for the new
functions, they are local for the main function as they were initially.



I believe that the attached example is self explanatory and I think you will
have no problem to adapt your programming style to this way of doing things.
And I am convinced that in the long run you will see that is much easier to
read, to flowchart, to maintain and to debug your code. Should you have any
other question, don't hesitate, just shoot 🙂



Good luck,



Constantin





a écrit dans le message de news:
5271140@discussion.autodesk.com...
Hi Gherasim and thank you very much for your great help.
First of all, sorry not to reply on your answer before. I have been tied up
with something else. I agree in all your comments and I send you a big
thanks for all your good advices. Best of all, your suggestion worked just
fine.

I have some further question about #3 comment. I wonder where you place your
code for each action_tile functions? Inside the function that control the
dialog box? As you see I have a lot of variables that I need to bring with
me into the function and I want to have as few as possible of global
variables to deal with.

\Freddy

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost