Upgrading Bricscad Pro V18.1 to V18.2.04

MrArch

I recently upgraded to the latest version, V18.2.04. I did so mainly for the Blade Lisp IDE. It is indeed a welcome addition to BricsCad. What I did not realize when upgrading is that BricsCad now checks and analyzes all installed lisp customization and I believe menu macros. The upgrade installation does save a backup but what I did not realize is that some customization, particularly partially loaded custom menu cui's need to be reloaded. I apparently had some remnants from AutoCAD that ran in Version 18.1 but won't in 18.2.04. I have the menu source files but if you only have the cui's, it can be a chore to revise custom menus.

I also found that Blade also checks the structure and syntax of all lisp customization and anything that calls AutoCAD specific applications or parts thereof. What did load in the past weather semantically correct or not may no longer work.

I reverted to loading only the default BricsCad cui, removing everything from On-Start, On-Doc and Appload for a fresh start. I then proceeded to reload all custom toolbar menus, lisp, etc. BricsCad. Blade is much more than just a lisp IDE, It can find most errors that may have worked in the past but with errors that are no longer acceptable.

I need a small amount of recoding to make a couple routines work again but for the most part I consider Blade a good addition to BricsCad and a great way to force needed housekeeping. My system now loads cleanly and I think faster than ever.

Thanks BricsCad!

Torsten Moses

Dear MrArch,

not sure what you mean with "is that BricsCad now checks and analyzes all installed lisp customization and I believe menu macros."

The normal Lisp processing is not affected at all by Blade :-)
If Blade is not open, there is no impact at all to Lisp loading + processing - and if Blade is open, it analyses the Lisp file content for the "Resources" and "Functions" panel tabs - but also no impact to Lisp processing.

"I also found that Blade also checks the structure and syntax of all lisp customization and anything that calls AutoCAD specific applications or parts thereof"
Yes, but as mentioned, only for visualisation inside Blade, no impact to Lisp processing by the Lisp core engine.

For V18.2 we had fixed 1,2 (long-time) defects where native Lisp functions were not 100% compatible;
and with V18.2.04 one bug was introduced (some notation for double values were not properly recognised) and one change for (repeat) function, which incorrectly accepted double values;
the bug was fixed with V18.2.05 ...

There was another detail in V18.2.04 : trying to load FAS/VLX file had shown a message box about, but was silently ignored in V18.1 and before ... reverted with V18.2.05, as seemingly a number of applications were affected, as those still try to load .fas/vlx files under BricsCAD :-)

If you have more specific samples what did work in V18.1 and now fails with V18.2, please feel free to show here (for other developers, potentially with workaround, if you have);
and if there is a true bug, please also send us a SupportRequest - we will do our best to get everything fixed :-)
many greetings !

Roy Klein Gebbinck

@Torsten Moses:
Making functions like (repeat) less tolerant is problematic for Lisp developers who primarily write for the BricsCAD platform. Will this policy one day also affect the vla-* function set?

Torsten Moses

Dear Roy,

for sure, that is not the policy :-)
The primary target is to maintain 99.9...% compatibility with AutoCAD AutoLISP - and regardless what the primary target CAD system is :

• when it runs in AutoLISP, it has to run in BricsCAD LISP
• when it fails in AutoLISP, it should identically fail in BricsCAD LISP
• when it runs in BricsCAD LISP (using standard AutoLISP functions), it also should run in AutoCAD

For the (VLA COM functions - here the compatibility level is at COM, so we need to match AutoCAD COM behaviour (except for serious bugs), as that COM interface also serves for VB/VBA/Delphi and other COM-enabled languages.

So in general, don't be afraid, such cases as with (repeat) are a clear exceptional case (also my personal preference is, to keep existing things still existing, as much as possible).
many greetings !

MrArch

@MrArch said:
I recently upgraded to the latest version, V18.2.04. I did so mainly for the Blade Lisp IDE. It is indeed a welcome addition to BricsCad. What I did not realize when upgrading is that BricsCad now checks and analyzes all installed lisp customization and I believe menu macros. The upgrade installation does save a backup but what I did not realize is that some customization, particularly partially loaded custom menu cui's need to be reloaded. I apparently had some remnants from AutoCAD that ran in Version 18.1 but won't in 18.2.04. I have the menu source files but if you only have the cui's, it can be a chore to revise custom menus.

I also found that Blade also checks the structure and syntax of all lisp customization and anything that calls AutoCAD specific applications or parts thereof. What did load in the past weather semantically correct or not may no longer work.

I reverted to loading only the default BricsCad cui, removing everything from On-Start, On-Doc and Appload for a fresh start. I then proceeded to reload all custom toolbar menus, lisp, etc. BricsCad. Blade is much more than just a lisp IDE, It can find most errors that may have worked in the past but with errors that are no longer acceptable.

I need a small amount of recoding to make a couple routines work again but for the most part I consider Blade a good addition to BricsCad and a great way to force needed housekeeping. My system now loads cleanly and I think faster than ever.

Thanks BricsCad!

It is difficult for me to show you all of what seems to have changed. I am fixing a couple routines that now report what sees to be much more verbose error reporting that from what I remember... and more info than what AutoCAD reports.

I have one routine that sets my preferred cad environment, contains some global functions and then loads about 30 lisp routines that I use all the time. It is called from on-start.lsp

The only problem I remember specifically was what actually was an Acad specific routine that BricsCad skipped over in v18.1 but a big dialog box popped up upon starting Bcad in V18.2.4 that said acadapp not found. It was an old routine that I don't use anymore, ddchprop.lsp. I had a hard time finding it too but once I removed it from my list the dialog went away.

There are a couple other routines that I know BricsCad now errors on and won't load but I haven't had the time to trace down the cause or the exact error message. It may be that I'm missing a variable or something that had previously loaded in another routine that I have disabled while I'm rebuilding my system and menus.

Torsten Moses

Dear MrArch,

that BricsCad skipped over in v18.1 but a big dialog box popped up upon starting Bcad in V18.2.4 that said acadapp not found.

yes, this extra message box (showing invalid (load) operation - intended to give developers more feedback to adjust & correct their code) has been rmeoved again in latest V18.2.05 ...
so best, try your code again with V18.2.05 :-)

many greetings !

Roy Klein Gebbinck

@Torsten Moses:
I am still worried.

In BricsCAD this is possible (point as list):

(setq lineObj (vlax-ename->vla-object (car (entsel))))
(vla-put-endpoint lineObj '(0 0 0))

In AutoCAD you have to use:

(setq lineObj (vlax-ename->vla-object (car (entsel))))
(vla-put-endpoint lineObj (vlax-3d-point '(0 0 0)))

In my mind this 'tolerance' is convenient and a feature of BricsCAD Lisp. But Judging by what you say I have to assume that this will change in a future release.

Torsten Moses

Dear Roy,

no, it will not change, because it is indeed convenient, and somewhat logical to support a plain point list;
because several other VLA COM functions in AutoLISP also support this, instead of vlax-3d-point.

But the main difference to (repeat 10.6) is :
(vla-put-endpoint lineObj '(0 0 0)) is logically correct ... while (repeat 10.6) is a kind of a logical fault - how to do the (repeat 0.6) part ?

While claiming on (repeat 10.6) can potentially indicate a wrong application/code logic, which should not get unnoticed, the (vla-put-endpoint lineObj '(0 0 0)) is correct from logical point.

many greetings !

Roy Klein Gebbinck

@Torsten Moses:
Thanks for the clarification. This makes sense.