Alpha 18 is released. I've fixed the tab control bugs that I was unable to get fixed in time for yesterday's Alpha 17 release, and I've also fixed splitter controls. You may have noticed that the bug list has been whittled down to just a handful of outstanding bugs. The code is getting stable and useable slowly but surely.
IMPORTANT NOTE: While working on splitter controls I discovered a really irritating problem. ODCL was writing dialog sizes and splitter positions to the registry into the default application profile. In AutoCAD, that means it was writing those values into the AutoCAD root registry key. Ugh! I fixed it so that it now writes into the current AutoCAD user profile (under OpenDCL\Dialogs), but all of you who have been testing (and presumably even those using older versions of ObjectDCL) should remove those subkeys from your main AutoCAD registry key.
You can find the junk keys by navigating to HKCU\Software\Autodesk\AutoCAD\<CurVer>\<Curver> and looking for subkeys that match names of forms you have opened in the past. The data is saved in the subkey, so you can just delete the subkey and it all goes away. If you're not comfortable mucking with the registry, just do nothing. The extra keys won't hurt anything (except perhaps slow registry accesses by a tiny bit).
There is only one outstanding problem that stops us from moving into beta mode: the backgrounds of controls don't match the background of the tab control. I've been thinking about how best to address this. The original code placed an extra window on top of the tab control and behind the controls on the page in order to overwrite the tab control's off white color. This is pretty kludgy, because you have to make some guesses as to how big the tab control border is, and you can't easily account for rounded corners or other amenities that have or will come along in newer versions of Windows.
A better solution would be to implement transparent backgrounds for all controls, and provide an option to set a control's background as transparent. This is a lot of work, and I don't really want to do it now because it will be much easier once all controls have been updated to the new architecture. I think the best solution for now is to give the tab control the same old gray background. Unfortunately, this isn't easy. I'll have to do all the control drawing in the ODCL code rather than let the tab control draw itself.
Since I'm basically lazy, I plan to cheat and use one of the open source tab control classes available on the net. This brings me to my point. There are a number of very nice tab controls with lots of bells and whistles, and if I plug in one of those fancy controls, there may be new capabilities available that you didn't have witht he old control (tabs on the bottom or sides, Windows XP themes, custom shaped tabs, etc.) When I go scouting for a tab control class, are there any really cool must-have features that you'd like me to look for? Reply here and let me know. I can't promise that the new properties would be available immediately, but I can at least try to find something that supports it so that the property can be easily added int he future. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>>> are there any really cool must-have features that you'd like me to look for?
Nothing special comes to mind ... I'm happy enough to get it working :-)
now go get some sleep !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-02-27
1. I use the Reg. Keys to re-show my forms in the last location..
(Odcl_Form_Show TMaRebar2_dclRebar2
(vl-registry-read (strcat "HKEY_CURRENT_USER\\" (vlax-product-key) "\\TMaRebar2_dclRebar2") "nTopLeftX")
(vl-registry-read (strcat "HKEY_CURRENT_USER\\" (vlax-product-key) "\\TMaRebar2_dclRebar2") "nTopLeftY")
)
So this is anther item that needs to be documented as an area where you will need to update your lisp code.
Now that I think about it, why should I have to do this? Why not add an optional argument to (Odcl_Form_Show T T) to re-show in the last location...
2. No must haves for me, as long as it works the same as the existing version without having to re-work a bunch of our code. Any new feature will just be a bonus....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Barry, all ODCl dialogs remember their last size and position, and get restored automatically. The only reason to feed a starting position to the (odcl_form_show) function is if you want to set a *different* starting position from what was saved. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Alpha 18 is released. I've fixed the tab control bugs that I was unable to get fixed in time for yesterday's Alpha 17 release, and I've also fixed splitter controls. You may have noticed that the bug list has been whittled down to just a handful of outstanding bugs. The code is getting stable and useable slowly but surely.
IMPORTANT NOTE: While working on splitter controls I discovered a really irritating problem. ODCL was writing dialog sizes and splitter positions to the registry into the default application profile. In AutoCAD, that means it was writing those values into the AutoCAD root registry key. Ugh! I fixed it so that it now writes into the current AutoCAD user profile (under OpenDCL\Dialogs), but all of you who have been testing (and presumably even those using older versions of ObjectDCL) should remove those subkeys from your main AutoCAD registry key.
You can find the junk keys by navigating to HKCU\Software\Autodesk\AutoCAD\<CurVer>\<Curver> and looking for subkeys that match names of forms you have opened in the past. The data is saved in the subkey, so you can just delete the subkey and it all goes away. If you're not comfortable mucking with the registry, just do nothing. The extra keys won't hurt anything (except perhaps slow registry accesses by a tiny bit).
There is only one outstanding problem that stops us from moving into beta mode: the backgrounds of controls don't match the background of the tab control. I've been thinking about how best to address this. The original code placed an extra window on top of the tab control and behind the controls on the page in order to overwrite the tab control's off white color. This is pretty kludgy, because you have to make some guesses as to how big the tab control border is, and you can't easily account for rounded corners or other amenities that have or will come along in newer versions of Windows.
A better solution would be to implement transparent backgrounds for all controls, and provide an option to set a control's background as transparent. This is a lot of work, and I don't really want to do it now because it will be much easier once all controls have been updated to the new architecture. I think the best solution for now is to give the tab control the same old gray background. Unfortunately, this isn't easy. I'll have to do all the control drawing in the ODCL code rather than let the tab control draw itself.
Since I'm basically lazy, I plan to cheat and use one of the open source tab control classes available on the net. This brings me to my point. There are a number of very nice tab controls with lots of bells and whistles, and if I plug in one of those fancy controls, there may be new capabilities available that you didn't have witht he old control (tabs on the bottom or sides, Windows XP themes, custom shaped tabs, etc.) When I go scouting for a tab control class, are there any really cool must-have features that you'd like me to look for? Reply here and let me know. I can't promise that the new properties would be available immediately, but I can at least try to find something that supports it so that the property can be easily added int he future. :)
>>> are there any really cool must-have features that you'd like me to look for?
Nothing special comes to mind ... I'm happy enough to get it working :-)
now go get some sleep !
1. I use the Reg. Keys to re-show my forms in the last location..
(Odcl_Form_Show TMaRebar2_dclRebar2
(vl-registry-read (strcat "HKEY_CURRENT_USER\\" (vlax-product-key) "\\TMaRebar2_dclRebar2") "nTopLeftX")
(vl-registry-read (strcat "HKEY_CURRENT_USER\\" (vlax-product-key) "\\TMaRebar2_dclRebar2") "nTopLeftY")
)
So this is anther item that needs to be documented as an area where you will need to update your lisp code.
Now that I think about it, why should I have to do this? Why not add an optional argument to (Odcl_Form_Show T T) to re-show in the last location...
2. No must haves for me, as long as it works the same as the existing version without having to re-work a bunch of our code. Any new feature will just be a bonus....
Barry, all ODCl dialogs remember their last size and position, and get restored automatically. The only reason to feed a starting position to the (odcl_form_show) function is if you want to set a *different* starting position from what was saved. :)
I've tried both ways. With the X&Y and without. The dialog always returns to the center of the screen.