Bricscad bug

Started by honkinberry, March 12, 2012, 11:09:51 AM

Previous topic - Next topic

honkinberry

I have something that is erroring only on Bricscad, of course not sure if this is on your end or theirs, maybe you can point me in the right direction.

Basically very simply, I am spawning another Modal dialog box from the first one, yet when I come back to close the first one, I am getting an error.  It seems it could be because I am using the same names for my local callback functions, but that should be acceptable I would think, yes?

Anyway, test code attached.

From Test function, click the button to Spawn the other dialog.  Click Ok to close, then click Ok to close the first dialog.  You should get the following error:

; ----- LISP : Call Stack -----
;
  • ...C:TEST
    ; [1].....DCL_FORM_SHOW <<--
    ;
    ; ----- Error around expression -----
    (AL_LEAVEDEFUN *RES*)
    ;
    ; error : bad argument type <#<<FUNCTION> #x3b @48e6be5e>> ; expected <FUNCTION> at [FUNCALL]
    ;
    ; error : during LISP function [c:dclButtonClicked] invoke from BRX/SDS interface,
              please check Lisp function definition and call arguments.

    --J

roy_043

#1
It is a strange problem but it is definitely caused by the c:dclButtonClicked functions having the same name. If you rename the function in c:spawn (and change the dcl accordingly) the problem goes away.

I have added some (princ) and (print) statements to your code because I suspected that it might be a scope issue. Below is the modified code and the resulting command line history. The strange thing is that the scopes for the c:dclButtonClicked functions appear to be correct, but BC seems to call an entirely different function when closing the first dialog after the spawn action.

If I retry the modified code in the same BC session the function IDs (I don't know if 'ID' is the right word here) that the code prints to the screen are new but the function ID in the error report stays the same.

Code (autolisp) Select

(defun c:spawn (/ DCLFORM c:dclButtonClicked c:dclInitialize)
 (defun c:dclButtonClicked ()
   (dcl_Form_Close (eval (read dclform)) 1)
 ) ; ButtonClicked
 (setq DCLFORM "test_form2")

 (princ "\nc:dclButtonClicked in c:spawn: ")
 (print c:dclButtonClicked)

 (dcl_form_show (eval (read dclform)))
 (princ "\nc:spawn is done! ")
) ; spawn

(defun c:test (/ DCLFORM c:dclButtonClicked c:SpawnDialog c:dclInitialize)
 (defun c:dclSpawnDialog ()
   (c:Spawn)
   (princ "\nBack... ")
   (princ "\nc:dclButtonClicked in c:test: ")
   (print c:dclButtonClicked)
 ) ; SpawnDialog

 (defun c:dclButtonClicked ()
   (dcl_Form_Close (eval (read dclform)) 1)
 ) ; ButtonClicked

 (defun c:dclInitialize ()
   (princ)
 ) ; Initialize

 (princ "\nc:dclButtonClicked in c:test: ")
 (print c:dclButtonClicked)

 (command "_.OPENDCL")
 (dcl_project_load "test" t)
 (setq DCLFORM "test_form1")
 (dcl_form_show (eval (read dclform)))
) ; test



: test

c:dclButtonClicked in c:test:
#<<FUNCTION> #x33 @6c290fbe>
: _.OPENDCL
c:dclButtonClicked in c:spawn:
#<<FUNCTION> #x33 @6c2910a6>
c:spawn is done!
Back...
c:dclButtonClicked in c:test:
#<<FUNCTION> #x33 @6c290fbe>
; ----- LISP Error : Call Stack -----
; [0]...C:TEST
; [1].....DCL_FORM_SHOW <<--
;
; ----- Error around expression -----
(PRINT C:DCLBUTTONCLICKED)
;
; error : bad argument type <#<<FUNCTION> #x3b @6c57f75e>> ; expected <FUNCTION> at [FUNCALL]
;
; error : during LISP function [C:DCLBUTTONCLICKED] invoke from BRX/SDS interface,
         please check Lisp function definition and call arguments.

honkinberry

Yet the functions are local, so that shouldn't be an issue.
So is it a bug with Bricscad, or with the OpenDCL build for Bricscad?

As it is not an issue on the AutoCAD side, I have to consider this a bug rather than gentle encouragement to stop making my code so portable and instead have every control and every callback function named uniquely for the form they relate to.

--J

owenwengerd

It certainly appears to be a Bricscad bug, and I recommend to report it to them directly.
Owen Wengerd (Outside The Box) / ManuSoft

honkinberry

Thanks, Owen, will do.

Cheers!

--J