StrongED 4.69f7 released

Hi All,

The seventh full release of StrongED 4.69 can found on the website

This release fixes a number of bugs that have been found in 4.69f6. A couple of the add-ons that come with StrongED have also been updated.

StrongED 4.69f7 is distributed under the 3-clause BSD licence, and not the GPL-3 licence used for earlier releases of 4.69. This is largely due to StrongLib which is also being used for StrongHelp and StrongMen, both of which are not distributed under the GPL (nor are they likely to).

As the GPL is unclear as to what exactly constitutes linking the licence has been changed to ensure it’s safe to include code from StrongLib.

With this issue resolved I expect to release the sources to SE 4.69f7 soon, just need to go over it as the build system has changed quite a bit from the previous source release.

As always, all feedback is welcome and appreciated!

Cheers,
Fred.

Changes in StrongED 4.69f7 (from 4.69f6)

• When a bar caret was used bits of the caret could be left behind after the text was reformatted by smart indent.

• Dragging the sliders in the ColourPicker didn’t move in real time.

• Killing a view from the LoW would abort if it was the only view on a text.

• Clicking on the last SWI name in a LoF for a module could abort.

• Searching in Dump mode would abort on ARMv7 if the display mode wasn’t ASM.

• When caret flashing was turned off when the caret was in the off state it would remain off.

• Undoing a caret move didn’t update the caret position field on the Infobar.

• When StrongED owned the clipboard, pasting the clipboard content in a savebox didn’t work.

• Changing the filetype in a savebox could cause bits from the previous sprite to be left behind.

• Selected views in the LoW could have their own colour but the Colours section of the Global Choices failed to list the item.

• Turning off the Infobar would cause the view to be moved to the back of the window stack.

• Trying to load a file using the file history menu aborted if the file could not be found.

• The DigDirSED add-on (searches files in the same dir) didn’t pass the filetype list to Lua correctly so including / excluding filetypes didn’t work.

• The KeywordFix add-on (converts BASIC keywords to uppercase) didn’t treat ‘=’ as a terminating character so failed on ‘=true’ as ‘true’ wasn’t recognised as a keyword.

• The SpeakSED add-on has been updated tp the latest version. Gives a more user*friendly error message when it can’t find eSpeak. Brief StrongHelp manual added.

With this issue resolved I expect to release the sources to SE 4.69f7 soon,

The sources to StrongED 4.69f7 are now available from the website.

Hi Fred,

Using the latest version, and it’s really great. The now very quick and robust outline font support is particularly appreciated.

I have one query: I’ve saved the window positions for the main viewer and also the List of Found window, so that every time I click on the List Functions/Procedures button from the BASIC mode toolbar the functions are displayed in a list to the left of the main window. The x/y location of this function list window is remembered correctly, as is its width, but the height doesn’t seem to be. The height of the function window seems to extend to the height of the screen (assuming the list itself is long enough), rather than limiting itself to the height it was when its position was saved. Is this a glitch? If so, is it fixable?

Thanks Chris, adding outline font support was an interesting experience. :-)

The height of the LoF window is adjusted to the height of the contents so this is intentional. It shouldn’t be too hard to add an option to always open with default values but I need to figure out where to put that in the UI, it’s getting a bit crowded.

Whilst on the subject on adding options, I use StrongED for the best part of 12 hours a day and have 20+ windows open. One thing I’d love to see is the ability to hide windows and have a list off the StrongED menu to select them.

An option to change the right click on the app to bring up the Window list instead of Modes was my first thought, along with a button in the editor windows to hide them.

A great bit of software though, its good to see its still being actively developed.

Jon, it’s a bit surprising that you haven’t found the window list which does exactly what you want. It’s been there for ages, I think I need to advertise StrongED’s features more. :-)

The List-Of-Windows (LoW for short) can be opened permanently from the iconbar menu or through Ctrl-L. It can also be opened transiently using Shift-Up/Down. To open a view simply double-click on it in the LoW.

The LoW allows you to select multiple views in a way similar to the Filer. It’s also possible to select views based on certain criteria, changed/unchanged, filetype, (part of) filename.

A number of actions can be carried on the selected views:

 - Save, to save the selected views (well, texts actually)
 - Kill, to delete selected views. If it's the last view on the text,
   the text is also deleted (whether changed or not so use with care)
 - Hide, to hide the selected views behind the backdrop
 - Icon, to iconise the selected views to the Pinboard
 - Show, to open (ie un-hide, un-iconise) the selected views
 - Close, to delete selected views but saved first if changed

There are also a few key bindings that you may find useful:

 - c-H to hide the current view
 - cs-H to hide all open views

I really couldn’t do without the LoW as I have about 50+ files loaded in StrongED permanently.

I have the LoW open all the time, but it doesn’t help hide the windows and it takes up a large chunk of the screen with so many windows open.

If you do consider adding a hide option, it just makes sense to have the LoW available quickly from the app icon as a right-click menu instead of a separate window. Just change the contents of the Modes menu to be the LoW.

That would really make my life easier as I’m constantly having to open/close windows and open/close the LoW so I have enough desktop space to see the code.

I should probably point out I develop on RiscOS 3.71 under emulation on a laptop with it running at the native laptop res so I’ve hit the physical limit of desktop space. I’m hoping someone will bring out a high res Pi laptop so I can switch, but it’s not looking hopeful.

 - c-H to hide the current view
 - cs-H to hide all open views

Doh, looks like what I want is mostly there, it’s just the right-click LoW menu that’s missing. Guess I can live with pressing CTRL-L instead.

Can CTRL-H be added as a button to windows? Perhaps I should read the help in more detail!

EDIT: In my defence I have seen CTRL-H in the help before, but mistakenly read it as “hide text” and not “hide window”

I have the LoW open all the time, but it doesn’t help hide the windows

It does, just select the view(s) to hide and click Menu over it, then Hide > Selection.

Can CTRL-H be added as a button to windows?

Yes! You probably want this available in all modes so the button needs to be added to BaseMode. Open the BaseMode ModeFile by Ctrl-Adjust click on the iconbar icon, then locate the functions section and add the following lines:

   Icon     <sprite name>
   Help     <help text>
   Select   HideView

Make sure the lines are separated from the other definitions in the section by an empty line before and after.

The sprite needs to be in the Wimp’s pool or in the BaseMode’s sprite file. The help text may be the literal text or a message token (looked up in BaseMode’s messages file).

After saving, the new button should become available.

Yes! You probably want this available in all modes so the button needs to be added to BaseMode

Thanks for the advise, works perfectly.

It shouldn’t be too hard to add an option to always open with default values but I need to figure out where to put that in the UI, it’s getting a bit crowded.

Thanks Fred. Would something like Shift-clicking on the buttonbar icon be the simplest method?

Would something like Shift-clicking on the buttonbar icon be the simplest method?

I’m thinking about adding a small dialogue box to the buttons for default position. Similar to the buttons for default dbox flags.

The dialogue box would show the coordinates and have a couple of option buttons. One option to force use of default values each time a window is opened, and another to allow a small offset from the previous window so they don’t fully overlap. Does that sound reasonable?

The dialogue box would show the coordinates and have a couple of option buttons. One option to force use of default values each time a window is opened, and another to allow a small offset from the previous window so they don’t fully overlap.

Sounds great, Fred. In my case I’d want the windows to open exactly on top of one another, but I can imagine the offset option being handy.

Also in my case, the following would be ideal: if a LoF window doesn’t have sufficient func/procs listed to match the default stored window coords, it would be opened at the top y coordinate and extended downwards as far as possible (rather than, say, placed in the middle of the range). Does that sound sensible?

if a LoF window doesn’t have sufficient func/procs listed to match the default stored window coords, it would be opened at the top y coordinate and extended downwards as far as possible

That’s what I had in mind too. The Top left coordinates are always the same, as is the width. The height would be sufficient to show all matches but not bigger than the configured height.

Sounds great!

Now, what are the odds of using Corpus.Medium in LoF windows, so I never have to look at the System Font again? ;-p

Support different fonts for LoF (and other windows that still use the system font) has been on the wish list for some time. Ideally it would generate a redraw list rather than direct calls to OS_Plot and OS_Write. Redraw lists are used to redraw the text in views and can use all of StrongED’s output options (system font, bitmap fonts, outline fonts and ViewFinder).

It is quite a big job though, especially for bitmap fonts¹ as StrongED has to do all the work itself including clipping to the graphics window. So, good news is I know what needs to be done, I just need to find the time and energy to actually do it.

¹Support for bitmap fonts has been extended in StrongED 4.70, it now allows characters of up to 32 pixels wide and of any height.

Yes, that does sound like a big job. It’s obviously only a cosmetic thing, but since the main view is now so configurable the System Font does stick out a bit more.

I wish you luck in finding both time and energy :)

In response to Jon Abbott’s comment:

> I should probably point out I develop on RiscOS 3.71 under emulation on a laptop
> with it running at the native laptop res so I’ve hit the physical limit of desktop
> space.

When I used to run RO3.7 under VRPC on a laptop (having previously been used to a much larger pair of screens) I had to change my working methods a bit, and one change that helped a lot was to use Steve Revill’s !MoreDesk. I should think you could have StrongED open lesser-used windows on other desktops.

Stupid question, but, when do you think that the website will be online again? I have StrongEd 4.67, but need some modes :)

Stupid question, but, when do you think that the website will be online again?

I need to update as well. Fred, you’re welcome to attach it on the JASPP forum temporarily, I can always remove the post once the site does come back.

For the moment, I’ve uploaded a cut-down version of the StrongED website here

This only contains the last stable release (4.69f7), last test release (4.70a7) and the modes. All the older releases have been left out but that’s probably not a major issue. Please let me know if you find anything wrong with this site.

Thanks!

Seconded

Fred, is there any documentation on how the ColoursStd file works? I’m trying to fix the issues with the colouring in BasASM, which I’ve modified for ExtASM use, but can’t get certain colour groups to actually set the colour defined.

EndOfFlt on Group 7 (FPU instructions) for example seems to break FPU instruction colouring. If I change it to EndAlways it goes to a red background, but changing the Group 7 colours makes no difference.

is there any documentation on how the ColoursStd file works?

No, they’re simply read by StrongED when a mode is used for the first time. The format of the file is easy:

 - Foreground colour in BBGGRRFF.
 - Background colour in BBGGRRFF.
 - Flags, bits 1,0 determine if colours for group is used or colours for text.
   Corresponds with state of None button in ColourPicker.
 - Name of bitmap style to use for the group.

It’s best not to alter the Colours files by hand but to use Mode Choices > Colours as this takes direct effect. Manually altering the Colours files means you’ll need to restart StrongED to see the effect.

I’m trying to fix the issues with the colouring in BasASM,

Any particular reason for not using extASM mode?

EndOfFlt on Group 7 (FPU instructions) for example seems to break FPU instruction colouring.

In what way?

Assembler colouring is a bit of oddball. Due to condition codes there a great many possible instructions which could result in a very large syntax tree. To cut this down to reasonable proportions various EndTypes have been created that match instruction specifiers.

The syntax groups only list the base mnemonic with the EndType matching the rest. For most FPU instructions the basic format is ABScpr where ABS is the base mnemonic and cpr stand for; condition code, precision, rounding mode.

Condition code and rounding mode are optional but if the instruction takes a precision then it must be specified.

If I change it to EndAlways it goes to a red background, but changing the Group 7 colours makes no difference.

The ModeFile is re-parsed when saved but, as explained above, the Colours file is not.

Thanks for the explanation, I mistakenly believed saving the Mode file was refreshing the colours as well, which will explain why I was seeing no effect.

It’s best not to alter the Colours files by hand but to use Mode Choices > Colours as this takes direct effect.

The More button seems to be permanently greyed out, it was my first port of call before manually editing. I’m assuming “More” is for editing the group colours.

Any particular reason for not using extASM mode?

I’m used to BasASM and use it across both BASIC assembly and ExtASM files – my code base uses both.

EndOfFlt on Group 7 (FPU instructions) for example seems to break FPU instruction colouring.

In what way?

My fault then, I wasn’t specifying the precision on the instruction.

Oh, one last thing. Is it possible to change the way the Undo/Redo button works so you can hold it down instead of repeatedly clicking. I sometime have to rollback lots of code to quickly double check behaviour before and after – I know it’s not meant for that, but its quick and easy.