Tag Archives: Torsten Moses

BLADE – putting things back to “normal”

2 Replies

Disclaimer: I’m making money using BLADE. I’m using it on a paying project right now (well, not while I’m typing this, but you get the idea). I’m developing a routine to automate a massively repetitive task for one of my AutoCAD-using clients, and I’m developing it in BricsCAD and BLADE rather than AutoCAD and VLIDE.

I can simply develop faster in the more modern environment, and BricsCAD’s significantly quicker start-up time helps with that. So does the fact that the routine runs several times faster in BricsCAD, making testing the large data sets much more efficient. I’m getting paid on results and not by the hour, so using BLADE is putting cash straight into my pocket while giving me more time to walk my dog.

Using BLADE in production, I’m discovering a few bugs, quirks and things I don’t like. That’s totally understandable with a new feature of this level of complexity and functionality. Where I think it makes sense, I’m submitting problem reports or feature requests to Bricsys. I’m sure Bricsys already has a bunch of these from other developers, so they’ll be very busy for a while. From past experience, I know my reports will be taken seriously and acted on appropriately in a timely manner, if it’s feasible to do so. Your LISP IDE feedback won’t be ignored for decades by Bricsys.

One of the things Torsten Moses mentioned to me that didn’t make it into the published interview was that many developers are very conservative. There’s some truth in that. I’m missing certain keystrokes, for example: 1978-era WordStar Ctrl-Y to delete a line, anyone? It’s a reasonable expectation that as more VLIDE users migrate to BLADE, many requests will come in for VLIDE-like things. I’m told that some of these things will be provided in coming months.

In the meantime, there are things we conservative developers can do to make ourselves feel more at home. One of these is to configure the editor appearance. Here’s the VLIDE editor:

Here’s the BLADE equivalent:

One of the great things about BLADE is how configurable it is, and I know Torsten’s working right now on making it even more so. Configurations are stored in the Registry in a version-independent location (HKCU\Software\Bricsys\BricsCAD\VLispDbgEditor). These can be exported and imported directly or via BLADE, so multiple complete setups and configurations can be managed.

In this post, I’m going to be going through the process of configuring BLADE’s editor appearance to make it look more like VLIDE. I’m not suggesting that’s necessary or even a good idea in most cases, but if you really want to do it, here’s how.

Note: before you do all this manually, please note that at the end of this post I will provide a configuration file that will do it for you.

  1. Start up BricsCAD V18.2 or later and start BLADE using either the BLADE or VLIDE command.
  2. Open a LISP file in BLADE so you can check the effects of the changes we’re going to make.
  3. Use Preferences > Show preference dialog…
  4. In the Preferences & Settings dialog, pick the Styles tab and the Lexer Styles sub-tab.
  5. I’m perfectly happy with Courier New 10, but if you want the VLIDE look, change 1 – Default text to Fixedsys 11.
  6. Click next to 3 – Comment, turn on the Background color toggle and change the Back Color to mid-grey (192,192,192) and Fore Color to dark magenta (128,0,128). You’ll need to specify that RGB value in the lower right corner and use Add to Custom Colors to do this.
  7. Click next to 5 – String and change the Fore Color to magenta (255,0,255).
  8. Click next to 7 – Operator and change the Fore Color to red (255,0,0).
  9. The 8 – Keyword 1 setting should already be blue as in VLIDE. If you want system constants such as T, nil and pi to also be that shade of blue then change 9 – Keyword 2 accordingly. Personally, I prefer a different shade so they stand out. Mid-dark cyan (0,128,192) works well.
  10. I like the pale grey background in BLADE that helps identify the current line. If you don’t, click next to 8 – Caret colour and turn off the Background color toggle.
  11. Switch to the Editor Colors sub-tab, click next to 5 – Selection colour and change the Back Color to a custom mid-blue (0,120,215).
  12. While you’re in the Editor Colors sub-tab, there are a few other non-VLIDE things you can play with. 1 – Brace hilight and 2 – Brace mismatch are dynamically applied to matching and non-matching parentheses respectively. I like my Brace hilight setting to be plum and bold (turn on the Attributes toggle to enable this):

I like my non-matching setting to be white on red (the inverse of a normal parenthesis so it shows up):

Changing all that should give you something that looks like this. Familiar enough?
There are several things in the above image that might be unfamiliar but which I suggest you leave turned on because they’re useful. If you really insist, here are the locations for these settings in the Preferences & Settings dialog:

  1. Line numbers  – View > Margins, Show line number margin
  2. Marker margin – View > Margins, Show marker margin. If this is turned off, bookmarks show up using the settings under Styles > Editor Colors > 13 – Bookmark marker.
  3. Edge marker (that vertical line on the right indicating 80 character width) – View > Edge marker > Type, No background.
  4. Indentation guides (those vertical lines that show you what your code is lining up with) – Tabs and EOL > Indentation, Show indentation guides.
  5. Code folding margin (the margin on the left that allows you to collapse functions, etc. – Folding and Wrapping > Show code folding margin.

Unlike VLIDE, the default in BLADE is to use spaces for indentation, not tabs. As I don’t know of any LISP developer who uses tabs except by accident, this is a much more sensible default. But if you really want to use tabs, turn it on using Preferences > Use tabs and set the width to the VLIDE default of 8 in Preferences > Set tab width.

If you’ve left opening parentheses on previous lines and have indented the following code as usual, then as you go on to finish off the code with closing parentheses, in BLADE a single backspace will take you back your indent width (2 spaces by default) rather than a single space as in VLIDE. If your coding finger can’t get used to this keystroke-saving feature, you can turn this off with Preferences > Backspace unindents.

Having done all that, and having arranged the rest of the interface to your needs (overall window size, pane and field widths, etc.), make sure you save it! It’s as simple as Preferences > Save preferences, but it’s not done automatically. If you want to keep a safe copy of your settings, you can do so with Preferences > Save preferences to file. This simply exports the relevant part of the registry to a .reg file of your choice. This is a text file you can hack about with at your leisure (using BLADE if you like!), and you can even make files that represent subsets of your preferences.

For example, I’ve removed all but the style settings from a .reg file I exported. I’ve uploaded it renamed as a .txt file because .reg files are considered dangerous by browsers, etc.

If you want to use this to give BLADE that old familiar VLIDE look, here are the steps.

  1. Download SteveVLIDE-likeBLADEStyleSettings.reg.txt.
  2. Rename the file to remove the .txt extension so it becomes SteveVLIDE-likeBLADEStyleSettings.reg.
  3. In BLADE, use Preferences > Load Config from File
  4. Close BLADE and BricsCAD.
  5. Restart BricsCAD and BLADE.

That should do it. Happy BLADEwork!

BricsCAD documentation – a tale of three systems – part 3

11 Replies

In this third post in what was supposed to be a two-part series, I have more to say about the BricsCAD documentation system. See here for part 1 and here for part 2.

Developer Help – Addendum

In this comment from Bricsys API person Torsten Moses, he informed me about the availability of the Lisp Developer Support Package (LDSP) in the Bricsys Application Catalog. As always, when presented with new evidence I am prepared to re-examine my position on anything. Therefore, I will now further discuss the BricsCAD developer documentation.

The first thing to mention is that the existence of the LDSP package is not obvious. To somebody who uses BricsCAD as-provided and as goes burrowing down through the Help system looking for information, that system is still broken. The documentation as presented to the user remains sub-standard, exactly as described in part 2.

Assuming you know of the existence of LDSP, how do you go about using it? Here are the steps:

  • Go to the Bricsys Application Catalog site, click in the search field and start typing LDSP (you don’t need to hit Enter).
  • The link to the Lisp Developer Support Package (LDSP) will appear: click that.
  • Enter your email address, accept the privacy agreement and pick Download. (Note in passing that this is actually published by Torsten’s own company, not Bricsys).

  • If you’re already a registered Bricsys user (you will be if you’re evaluating it), the download will start. If not, you’ll be expected to register (free):

  • Once you’re registered, the download results in a 12 MB file called Lisp Developer Support Package.rar (RAR is a ZIP-like format).

Any recent commercial ZIP utility (e.g. WinZip) will open RAR files and there are a variety of freeware/adware/shareware utilities available to do likewise. For example, RAR Opener in the Windows Store will present itself as the first option in Windows 10. But it goes without saying that going off in a hunt for utilities wouldn’t be on anyone’s expected to-do list when just looking for product help. A bunch of people would give up here, if not earlier.

I went through with installing RAR Opener, but when I attempted to open the LDSP file I saw this:

Oh, and a handful of empty folders were produced. Is there an email waiting for me at work with the password (my Bricsys registration email is at work but I’m at home)? Am I really supposed to have a password to open this RAR? If so, why wasn’t I prompted for one? RAR Opener doesn’t present me with that option anywhere I can see. Is the download corrupt? Does it refuse to work on a Sunday? I have no idea.

At this stage, many more would give up. How many prospective customers would be filtered out by this experience? There’s no way of knowing. However, I’m made of sterner stuff and persevered with downloading and installing another app from the Windows Store. 9 zip did the job and uncompressed the file, no password required.

Yes, the RAR Opener problem I had above isn’t a Bricsys problem directly. But it is indirectly, because the file I was given to deal with won’t open by default in Windows, where the vast majority of BricsCAD users will be working. It’s a level of obfuscation that you can get away with when dealing with cellar-dwelling geeks handling obscure pieces of open source software. It’s not appropriate for customer-facing documentation in a mainstream CAD application. Yes, even developer documentation, because with CAD applications like AutoCAD and BricsCAD, most of the developers are customers/users/managers, not people trying to sell utilities.

Once you manage to get the file uncompressed (it becomes 41 MB), there are three help systems provided in there (CHM, PDF, HTML). That’s excellent, and conforms nicely with the Bricsys philosophy of providing customers with choice. I was unable to find any broken links. However, even in the LDSP, standard AutoLISP functions are undocumented. So I still couldn’t find the (entget) help I was looking for in part 2:

According to Torsten:

…the standard AutoLISP functions like (entget) are not documented, as there are plenty docs on the web for this; but we document any extension beyond AutoLISP standard, even for the standard functions.

Sorry, but while “we don’t have that information but you can Google it” might have been an acceptable answer for a cheap AutoCAD clone’s API documentation ten years ago, that’s not where BricsCAD is today and most definitely where Bricsys wants it to be in future. Just two days ago, Bricsys CEO Erik De Keyser sat across a table from me and told me that BricsCAD isn’t intended as merely an AutoCAD alternative, but must go well beyond that in order to prosper. He’s right. The BricsCAD developer documentation today is not compatible with that vision. I know it’s that way for historical reasons, but we’re now at a different point in the historical timeline.

Conclusion – Addendum

My conclusion from Part 2 remains valid, despite the existence of LDSP. Both Autodesk and Bricsys have work to do. Downloading LDSP will help with some of the BricsCAD developer documentation failings but leaves plenty behind. It also provides its own set of unfortunate challenges.

This isn’t just a technical and ease-of-use failing, it’s a marketing one. That’s because it acts as a stumbling block to conversion of AutoCAD sites to BricsCAD. Disaffected AutoCAD power users in small sites and CAD Managers from large sites are right now taking tentative steps to evaluate the suitability of BricsCAD to replace AutoCAD in their complex LISP-heavy custom environments. They’ll want to know what’s the same and what’s different so they can estimate the effort and cost involved in the transition before getting in too deep. I know this, because I’ve done it myself. The first thing they will come across in their search is disjointed, very inconvenient and incomplete. It presents a less-than-professional image.

Some potential customers, like me, will persevere and discover that the quality of the developer tools implementation far exceeds the expectation generated by the documentation. Others will give up well before they reach that stage, and that’s a shame.