Trouble with edit boxes

[hmspe]

First real project in ODCL.  I've worked on this about 6 hours over two days and am getting nowhere.  Probably something really simple.  I've read through all the samples and looked at most of the code posted in the forums but I'm coming up empty. 

Two problems:
1.  Reloading the lsp file in Autocad 2010 after editing the lisp in Textpad or the ODCL does not appear to update the files in Autocad -- I get the same operation as before the edits unless I close and re-open Autocad.  Is this normal?
2.  The first time I run this I can enter data, but the Cancel and OK buttons do not work.  If I exit (upper right X) then run again I see the previous data and the OK button works, but the variables that should print after close are all nil.  Before I added the edit boxes I could get data on the option buttons.

This is obviously a work in progress.  I don't have all the initialization done, and I haven't done anything with the bottom edit box yet.

Also, has there been a syntax change for edit boxes?  The samples seem to have the form c:faultdrop_FaultBox_AFC-data_OnEditChanged (NewValue /) but the GUI cut and paste shows the form c:AFC-data_OnEditChanged (NewValue /)

Any help would be appreciated.

Martin

[Kerry]

1.  Reloading the lsp file in Autocad 2010 after editing the lisp in Textpad or the ODCL does not appear to update the files in Autocad -- I get the same operation as before the edits unless I close and re-open Autocad.  Is this normal?

to force a reload of the ODCL when debugging , use the 'reload' flag:
(dcl_Project_Load "t:\faultdrop" T)

[Kerry]

Also, has there been a syntax change for edit boxes?  The samples seem to have the form c:faultdrop_FaultBox_AFC-data_OnEditChanged (NewValue /) but the GUI cut and paste shows the form c:AFC-data_OnEditChanged (NewValue /)

Some of the Events are named c:AFC-data_xxx because you have the VarName set to 'AFC-data' for those controls. You will get a solution that is less confusing if you forgo the use of the VarName property untill you are comfortable with the Editor.

[Kerry]

I haven't tried to load or run the code, so I haven't tested the OK and close issue ;
but I'd move the (print .... actions from the c:faultdrop_FaultBox_btnOK_OnClicked  into c:efault and
use a conditional to test the value of result after (setq Result (dcl_Form_Show faultdrop_faultbox))

ie use something like
(dcl_Form_Close faultdrop_FaultBox 1001) ; <== nore value

Then
(setq Result (dcl_Form_Show faultdrop_faultbox))
(cond
  ( (= 1001 Result)
        (do your mojo here)
  )
;....
)
 


This will also make the code easier to read (in my opinion).

[hmspe]

Kerry,

Thanks for the suggestions.  I'm getting closer but still have a few bugs to squash.  I'm finding this very frustrating -- I spent around 4 hours on this since you posted and nothing I tried seemed to do anything, then a few minutes ago I added a setq with a dummy variable to try to see if OnInitialize was firing (it did not seem to be since none of the fields were being preset), and suddenly it mostly works.  At this point I'm seeing:

   Command: EF
   Backtrace:
   [0.23] (VL-BT)
   [1.19] (C:EF)
   [2.15] (#<SUBR @000000002a93b0c0 -rts_top->)
   [3.12] (#<SUBR @0000000028f48700 veval-str-body> "(C:EF)" T #<FILE internal>)
   :CALLBACK-ENTRY.6 (:CALLBACK-ENTRY)
   :ARQ-SUBR-CALLBACK.3 (nil 0)
   _OPENDCL
   OpenDCL Runtime [6.0.0.24] loaded
   
   Command: ; error: bad argument type: consp 0
   
   1001
   << other variables are returning nil >>


No more time to play at the moment. 

[hmspe]

Followup:

The consp error was due to code in (defun set_AWGs   that should have been removed.  Everything after the end of the (cond   is unnecessary.

The "will not run on first open" problem was due to having the sub-functions inside the main function.  If the sub-functions are all independent the code runs on the first call.