Nesting 'horizontal' into 'vertical' (or vice versa) resets length to "1"

[DeliveryFry]

The third bug on my List of Annoying Annoyances. This one is reliably easy to reproduce, exactly what it says on the tin, and more. I'll expand on the "and more" further down.

Expected behavior

That stuff just works. (A shocking expectation, I know.)

Observed behavior

What I describe in the title: nesting horizontal into vertical (or vice versa) causes the second invocation to reset the line length to 1.

In truth, it doesn't even have to be "vice versa", it can be another invocation of the same command (only I couldn't figure out how to word all of that neatly into the title).

Steps to reproduce

Simple and straight forward, but first off, a quick explanation: what I mean by "nesting" is invoking a second command at the command line while a previous command is still active.

Okay, so let's say that from your prior usage of the line tools (horizontal, vertical, or the angle one), the length parameter has been set to 750.

Start a new drawing. Pick one of horizontal or vertical (it doesn't matter which) and invoke it at the command line. Key in a coordinate pair. The Origin is always a fun place to hang out, so heck, why not 0,0? There. You've created a new line of the expected length. So far so good. Don't dismiss the active command.

Now, back at the command line, type in the name of the same command again or use the other one, but before completing its invocation with [ENTER] or [SPACE] keep your eye on the Length field in the command's toolbar:

Now go ahead, and be amazed as you see it reset to 1. If you don't [ESC] out of this invocation right now ("—DANGER, Will Robinson! DANGER!!!—") and do accidentally place this new entity at this length, 1 will become the newly set length for all the line tools once you've dismissed this pair of nested invocations (more on this coming up).

So as you can well imagine, in a real-world situation while working on a complex, congested, and large-scale drawing, if you've failed to notice that the second invocation has miniaturized itself before placing it, you could quite literally drop the equivalent of 1cm-long needle into a 400m² haystack. This can lead to even more fun if you never realized this missing "needle" was dropped in the first place (say because you believed the command failed altogether without any real consequence) and it happens to have fallen into an area you later intend to hatch. "Hatch failed due to…"

Summarizing: A one liner to reproduce this bug is simply to input horizontal;0,0;vertical;0,0. And of course, inserting kill between the two invocations results in the desired, non-buggy outcome.

"And More" Bonus Weirdness: The Alternating Length Value

Everything I've described up to this point is what I've observed in my real-world usage, but in experimenting with this bug over the course of assembling this report, I've gotten it to exhibit a behavior weirder than anything I've witnessed under normal working conditions.

A few paragraphs ago I stated that the reset 1 will become the length of all the line tools once the nested invocations are dismissed. This sort of makes sense, as it was the last used value for that tool. I'd assumed the value set by the user was lost forever. But try this:

Open a new drawing. Set a fairly long line length with one of the tools, then enter this into your command line: horizontal;0,0. Using your up-arrow key, repeat this command over and over, stacking the lines atop of one another, counting your iterations as you go while watching the toolbar. If you get the same results I do, you'll see that the length now alternates between your assigned value and 1 over and over again.

Let's say you've counted out 6 iterations. Capture the Origin within the blue-selection rectangle. The status bar will tell you that you have indeed selected 3 entities with a total length of 3. Dismiss these selections and use the green-selection rectangle to grab the long lines instead. Yep, you've now selected 3 entities at 3× the length you'd intentionally assigned.

If you begin hitting [ESC] to dismiss the nested invocations while the length of the last placed invocation was 1 (an even number of total invocations), the length remains set at 1 once you've completely backed out of them. Otherwise, if you start backing out while the length of the last invocation was at your assigned value (an odd total of invocations), it will retain your assigned value.

Since in my real work I tend to key in intersections here and there with quick calls to horizontal, then vertical, it's no wonder that I always find myself stuck with the reset value of 1. But that's only because my nested invocations always occur in even pairs.

So, yeah, the twin discoveries that the values can alternate and that the user's assigned value isn't immediately lost forever came as quite a surprise to me.

Anyway, I think that's about as dead as I can beat this horse, er, I mean, report, so from here onward I'll leave it to wiser and more knowledgeable minds to decide what can be done about it.

Operating System and LibreCAD version info

My Linux distro is Mageia 8 (x86_64) and I'm using Plasma 5 (KDE Frameworks 5.76.0 with Qt 5.15.2) as my desktop.

This bug report was produced with my distro's LibreCAD-2.2.0-rc4

[lordofbikes]

This basically matches #1547 and describes a common issue with the command line. It seems, that 'nesting' was not intended by the developers here. So the recommendation for now is to push ESC to quit the active tool before firing the next command.

Using the tool buttons keep length values for horizontal and vertical, so this is an issue with command line. And changing the length value is just a follow-up of command 'nesting' Anyhow, using the command line should not differ from using menus or tool buttons and must be investigated. Not only for horizontal and vertical, but for all commands in general.

[DeliveryFry]

Hi LoB. Yeah, my two reports do seem similar enough to share the same underlying cause. Thanks for looking into this and the other one. I'm looking forward to one day seeing them both resolved.

Anyway, I haven't been back to pester you lately because, at some point between 2.1.3 and (my distro's now correctly patched) 2.2.0rc4, the remaining bugs on my list of Annoying Annoyances all seem to have been dealt with. I'm especially grateful to whoever stomped the bug where every time the auto-save kicked in the entire work area would bounce up and down. That one really drove me over the edge so I'm very happy see it gone. I also have a half dozen or so feature requests I eventually hope to get around to posting about.

So for the last few months everything LC has been going swimmingly… Then the other day I ran across another anomaly. It's nothing game breaking and possibly been around for a while, but I think it's something you and the team might want to look into before the next stable release. Hopefully it's got an easy fix. New report to follow soon.

Thanks again for all your hard work.