I've always been irritated by the project_form_control naming convention, and I'm thinking about what it would take to change the convention in OpenDCL 8. My main concern is the underscore symbol. I'd prefer something like project/form/control. For functions and methods, I'd prefer the hyphen as a delimiter to follow the visual lisp convention, so (dcl_Form_Show) becomes (dcl-Form-Show).
This is partly an aesthetic issue, but also partly a practical/functional issue. Naming controls like project/form/control makes it more intuitive to visualize the hierarchy, and makes it easier to work with nested forms (or tab pages) addressed like Project/Form/Childform/Tabpage/Control. The current naming convention becomes unwieldy when you start referring to nested controls with a "complete" path. For events handlers, controls or forms with an underscore character in their name result in confusing names using the current convention.
The question is, how painful will it be to transition. For events, it's no problem at all: old projects will continue to use the old name since the handler name is embedded in the project. For functions and methods I just have to create new function names, but leave the old names defined as well so that old code continues to work. It seems a bit messy, but for lisp symbol names I can also set both the old style and the new style names simultaneously so that old code will continue to work.
Am I missing anything? What do you guys think?
I've been looking at a project any examples and I liked the nomenclature especially in the event, it is easy to quickly identify the code by the symbol "#", in terms of functions and methods could create a small program to lisp files open and replace text.
as to the 8.0.0.1 version, I've tried to "MasterDemo" in ac2014 and presents some problems, but this is another matter and we will already talking.
Sorry for my bad English.
That's a good idea to make a small lisp utility to update lisp files. You have to be careful, because if controls include an underscore in their name, the conversion should be project_form_con_trol -> project/form/con_trol, which would require knowledge about the control name. I suppose the utility could open the .odcl and programmatically determine the correct control names. In that case it could even update event names, then save the modified .odcl and .lsp files.
Hi guys, I'm not really sure, if I should be glad about it. I'm even wondering about a special char like '/' is allowed in symbolnames. But it actually is. For my own taste, a '_'-char is more wide and it devides project, form and control much better and it matches much better to other object variables which use '_', too.
And I was not worry about '_' in function names - my .NET based Lisp-function names are also using '_' to seperate app-prefix, upper topic, sub topic and function from each other (like stadtcad_menu_ribbons_regen). But nevertheless, if any issues will be closed with that change, it should be done.
I'm thinking about a replacer for "'dcl_" and "(dcl_" (Search result of my old project "(dcl_" (11663 hits in 56 files)).
Regards, Fred
Hm, how about defining a custom seperator char for an odcl project for control naming in OpenDCL Studio?
Regards, Fred
Thanks for your input, Fred.
If anyone wants to experiment, I've attached a quick-n-dirty utility to update the symbol and function names in existing odcl projects. I've only done very limited testing with the _MasterDemo sample project. It's not bulletproof. For example, it expects default event handler names in the project, so it will fail to update event handler names if they are no longer default. Load and run UDCL8UPDATE, then select the .odcl files. It will look for and update a .lsp file of the same name, and it will make backups of both files.
After working with the update utility today and spending some time with the new naming convention, I'm pretty satisfied with most things about it. I'm not thrilled with the forward slash "path" separator, but I think it's better than the underscore, and I can't find anything better on a standard US keyboard. I guess adding an option for a user-selected separator would be one solution, but I know from all the places I had to modify the code to make this change that it's not simple to provide that flexibility.
Owen,
The have a little time, I will test the utility with some of my major projects to see what happens and that may have errors.
... and I do get results
Sorry I'm late to the game on this one Owen.
Are you saying existing projects (lsp & odcl) would have to be converted or will OpenDCL be backwards comparable?
Can I leave existing projects as-is & just use the new naming convention for new project?
Barry
Old projects should continue to work without modification.
Quote from: owenwengerd on January 03, 2014, 05:30:32 PM
If anyone wants to experiment, I've attached a quick-n-dirty utility to update the symbol and function names in existing odcl projects. I've only done very limited testing with the _MasterDemo sample project. It's not bulletproof. For example, it expects default event handler names in the project, so it will fail to update event handler names if they are no longer default. Load and run UDCL8UPDATE, then select the .odcl files. It will look for and update a .lsp file of the same name, and it will make backups of both files.
This utility will convert the project. Odcl with the new nomenclature?
In addition to the project. Odcl also need to convert individual files lisp related to it?
I understand it?
The discussion goes back to January, there are updates?
I have a very complex project and I'm not sure that it is convenient to update to the new nomenclature.
Maybe I can leave things as they are, but that I will have problems in the future with the maintenance of my project?
What should I do?
Yes, the utility updates the .odcl file and the matching lisp file.
If your old project converts cleanly, then I think it would be best to use the utility and convert it. If it does not convert cleanly, then it would be best to leave it as it is. At this point there has been no change since January. As you can see, only a few people have provided feedback. Without feedback, I will continue with the current implementation.
I state that I have not converted my project. Maybe I will in the coming days ...
However, I tried to enable an event to a control 'Combo Box' and then copied the code suggested in my lisp file:
(defun c:NomeApp_Form/FormMain/ColLayer#OnSelChanged (ItemIndexOrCount Value /)
(dcl_MessageBox "To Do: code must be added to event handler\r\nc:NomeApp_Form/FormMain/ColLayer#OnSelChanged" "To do")
)
but when i load the lisp file in AutoCAD displays the following error:
Command: (LOAD "C:/Documents and Settings/Anonimo/Desktop/TEST.lsp") ; errore: ads_defun
failed: <nome num cr>:
if I remove the "/" from the name of the function, then the lisp file is loaded correctly.
I don't understand. The error indicates that you added a \ character to the function name. Are you mistyping \ instead of /? In any case, I recommend to copy/paste from Studio instead of typing.
Quote from: owenwengerd on April 14, 2014, 07:42:30 AM
I don't understand. The error indicates that you added a \ character to the function name. Are you mistyping \ instead of /? In any case, I recommend to copy/paste from Studio instead of typing.
You are right.
I just tried with a new project and working properly.
However, for some reason in my project I do copy-paste the code from Openstudio, to the lisp file, but the error is issued when loading the lisp file.
I have just started a new ODCL project and, to my surprise, I actually like the new naming convention. It makes a lot of sense.
But I do notice a small thing (ODCL 8.0.0.6):
The 'Clipboard Copy' code for events still uses "dcl_MessageBox" instead of "dcl-MessageBox".
Thanks for the feedback, and good catch on the function name. I've now corrected the function name for the next build.
Quote from: owenwengerd on January 03, 2014, 05:30:32 PM
If anyone wants to experiment, I've attached a quick-n-dirty utility to update the symbol and function names in existing odcl projects. I've only done very limited testing with the _MasterDemo sample project. It's not bulletproof. For example, it expects default event handler names in the project, so it will fail to update event handler names if they are no longer default. Load and run UDCL8UPDATE, then select the .odcl files. It will look for and update a .lsp file of the same name, and it will make backups of both files.
Owen,
Thanks for this.
I'm updating about 20 projects for ac2015 ... decided to convert the ODCL event handlers and symbol names as well.
Faultless so far ... a very nice bit of code too.
Regards and Thanks
Kerry
That's good to hear, Kerry. Thanks for the feedback!
Quote from: Kerry on November 17, 2014, 11:32:43 PM
... decided to convert the ODCL event handlers and symbol names as well....
Is it correct that these values are not changed by the lisp and have to be modified manually?
Quote from: Peter2 on November 21, 2014, 12:24:52 AM
Quote from: Kerry on November 17, 2014, 11:32:43 PM
... decided to convert the ODCL event handlers and symbol names as well....
Is it correct that these values are not changed by the lisp and have to be modified manually?
No, the lisp attempts to modify everything -- but only if the original event names are the default forms.
Quote from: owenwengerd on November 21, 2014, 07:11:54 AM
...but only if the original event names are the default forms.
OK - that's the trick.
Thanks - the lisp works fine :)
After a long time I tried the lisp again ...
- I had a code in Version 7 (lsp and ODCL)
- I renamed both lsp and odcl filenames
- in Studio, I used the "Reset symbolnames.." and "reset events". I modified from c:xTB_Font_Check_dialog_OptSystemPlot_OnClicked
to
c:xTB_Font_Check/dialog/OptSystemPlot#OnClicked
- in Lisp-code, I also have the old code
(defun c:xTB_Font_Check_dialog_OptSystemPlot_OnClicked (intValue /)
- now I used the ODCL8Upd.lsp
-> Lisp and ODCL where backed up; both get the current filedate
-> but the content of the Lisp was not modified
Did I modify to much?
Just a guess, but you probably broke it by manually resetting symbol names and event names.
Finally I could not find why it was broken, but I restored my bak-files and the tool made its job without problems. Thanks.