Once I have the following sub loaded the palette pops back up as expected, but the onInitialize event won't fire - I have to hit my "refresh" button to populate the form.
This is the OnEnteringNoDocState sub:
(defun c:jb002_00_OnEnteringNoDocState ( /)
(if (dcl_Form_IsActive jb002_00)
(progn (vl-bb-set 'jbKeynotesFloating "true")
(dcl_form_close jb002_00)))
)
This is the OnDocActivated sub:
(defun c:jb002_00_OnDocActivated (/) (c:jb002_00_OnInitialize))
This is the OnInitialize sub:
(defun c:jb002_00_OnInitialize (/ file data)
(if (not(dcl_Control_GetValue jb002_00_note))
(dcl_Control_SetEnabled jb002_00_LEADER 0)
(dcl_Control_SetEnabled jb002_00_LEADER 1))
(dcl_Control_Setcaption jb002_00_PREVIEW "")
;;; Drawing specific keynote file
;(setq file (jb:ReturnKeynoteFilename))
;;; Project specific keynote file
(setq file(jb:ReturnKeynoteFilename))
(if file
(setq data (jb:getKeynoteFileData file)))
(if data
(progn (dcl_ListBox_Clear jb002_00_DIV)
(dcl_ListBox_AddList jb002_00_DIV (car data))
(dcl_ListBox_Clear jb002_00_ListBox)
(dcl_ListBox_AddList jb002_00_ListBox (cadr data)))
(progn (dcl_ListBox_Clear jb002_00_ListBox)
(dcl_ListBox_Clear jb002_00_DIV))))
This is the command entry point sub:
(defun c:jbkeynotesdialog (/ )
(if(not(member "jb002" (dcl_GetProjects)))
(dcl_Project_load "jb002"))
(if (not (dcl_Form_IsActive jb002_00))
(dcl_Form_Show jb002_00))
(princ))
This line of code is at the end of the .fas file - loaded at document start-up (from a menu .mnl file):
(if
(= (vl-bb-ref 'jbKeynotesFloating) "true")
(c:jbkeynotesdialog))
So the form pops up, but the OnInitialize event doesn't fire. It's not the OnInitialize sub becaues the "refresh" button just calls the OnInitialize sub. I have documented this in two seperate paletttes. Any thoughts? bug??
OK - I've cobbled together a little test palette - All my stuff relies on common subs spread out and it's hard to post any of that stuff. So here's a little example that includes the issues I've been having with palettes (and maybe you'll learn a little about the exotic end of motorcycles ;) )
The issues are:
Painting: notice that when the splitter moves there are painting issues with affected controls.
Splitter Control: Doesn't respect the Closest property restrictions.
Label Control: Can't be cleared with (dcl_Control_SetCaption 000_00_DESC "")
Tree Control: OnSelChanged doesn't fire.
Palette Form in general:
note OnEnteringNoDocState as referenced above.
Palette hides and shows, but won't re-hide.
No transparency yet.
Allow Docking property not honored.
To be able to test the OnEnteringNoDocState and isFloating events this routine needs to be loaded at startup - act acccordingly.
"000.lsp" is the DCL file
"jb020.lsp is the AutoLisp file
I could not reproduce the painting, splitter, or label problems. I suspect that you're using an older version of the runtime. Please check the version displayed at the AutoCAD command line when it loads to verify the version you're using.
The OnSelChanged problem was due to some missing resources. That is now fixed for Alpha 9. The OnInitialized event problem should also be fixed in Alpha 9. Please test it and let me know whether it works as expected in Alpha 9.
You are indeeed correct sir - I was using an old run time: painting problems solved. I eagerly look forward to alpha 9 . . . thanks.
Owen,
OnSelChanged still not firing on my test palette. OnClicked is the only way to work it.
OnInitialized event now works great - thanks.
Personally, I'm not sure at this time how important the OnSelChanged event is since the work around is the onClicked event - with a little more code. I'd like to see palettes reacting properly in the collapsed - expanded bit. Just an observation ;)
Hold on - now this is wierd: I popped over to architecture 2008 to see if a property data bug I found in ADT 2006 had been fixed. Low and behold it had. Long story short: the onSelChanged event for the tree control works in 2008 - but NOT in 2006. ???
I can reproduce the problem in AutoCAD 2006. That's a strange one. It seems that different versions of the tree control behave differently. I'll investigate.
Well, I learned something new. It seems there are different notifications depending on whether or not the control is in Unicode format. In any case, the problem should be fixed in Alpha 10.