Topic: Issues compiling to VLX

[MP]

Ok, if you write dynamic DCL you have to
1) Write more code and read much longer bumf;
2) Check  more errors and every slash around strings;
3) Check if DCL is created/exist/loaded. Some paranoiac antivirus software and latest versions of windows can prevent file I/O operations.
4) Rewrite your code every time then Autodesk fails with codepages...

I've been using the technique for 2 decades and none of the reasons you cite have ever been an issue. My experience is contrary to what you suggest -- coding overhead nominal and has more reliable and secure than shipping a companion dcl file or packaging one via the vlisp compiler (which doesn't encrypt packaged dcl). tl;dr: I've never had one of my users or customers report an issue. Not once.

[VovKa]

You can add DCL to your VLX app. Making DCL on the fly is very bad idea. 

there could be issues with dcls
read here https://www.theswamp.org/index.php?topic=47908.msg541261#msg541261

[ur_naz]

You can add DCL to your VLX app. Making DCL on the fly is very bad idea. 

there could be issues with dcls
read here https://www.theswamp.org/index.php?topic=47908.msg541261#msg541261

Wow, multylanguage apps is realy butthurt... When you going to support multiple languages you have to make multiple
* menu
* prompts (in lisp)
* help system
Better way is to do all in English.

Then you have problem with codepages you may just translate codepage one to another. When revert back if need. When dialogs are in separate files it is much easier to do and not changes lisp staff.

When you want to rearrange DCL within LISP you need to rewrite LISP. It is hard to do, because DCL stored in separate strings. This is good chance to get error as result.

Finally, DCL in LISP seems very very ugly 

[ribarm]

I've never attempted to compile to VLX, but after reading this I thought would (repeat 1) can be an alternative of a loooong (progn).

(repeat 1) is behaving exactly like (progn)... Check for 255 lines and fails in VLIDE; check for 254 lines and it passes test...

[MP]

On "making dcl on the fly" ... maintaining code and packaging code are distinctly different activities. Both are easy, enjoyable -- fun even. My maintained code is miles from ugly. On the other hand packaged code does not get scrutinized for aesthetics but for reliability, robustness ease of distribution etc. But alas, I evangelize fruitlessly.

[dgorsman]

Almost all of my dialogs are purpose built and centrally referenced from a network location, so there isn't much point in building them on the fly from code.  But as noted, any differences are mostly stylistic rather than technical.

[ur_naz]

Almost all of my dialogs are purpose built and centrally referenced from a network location, so there isn't much point in building them on the fly from code.  But as noted, any differences are mostly stylistic rather than technical.

Using network is the worse than creating a dialogue on the fly, because the server may be down or any update have bugs. Then stop the work of an entire workgroup. In my opinion, it is best to install the application locally and to enable its users to update their own. You can also divide users into groups depending on their experience. More experienced users will be the first to try out new features of the application, test the application performance and send error reports. Thus, it can safely carry out testing of the new features and their implementation. Finally, most of user not need any updates.They may get angry when something suddenly changes in their usual work.