Two little bugs---Bricscad exits on the close command/ Layer button freezes & One wish

Rodolphe Simon

Two little bugs

On Fedora 20 (64 bit) Bricscad V15

1. Bricscad completely exits the program upon the "close" command (from the command menu), obviously the "close" should only close the drawing, leaving the others open, and not "exiting". Problem is very repeatable and consistent.

2. Layer button will freeze the application. Problem is not very repeatable and seems to only happen after printing via CUPS.

One wish- To use the Ribbon Tool Bar alone without the small (classic) toolbars. Currently to achieve this, I must manually turn off the classic toolbars. Time consuming.

Tomas Polak

Hi Rodolphe,
you should file a Service Request. Not much will happen with bug reports in this forum.
I can only tell you, that I cannot reproduce the "close" command bug on my Fedora install.
Tom

John Hersey

 Hi - I have the same problem that "layer" will freeze the program and reported it as a bug. They were not able to reproduce the problem, even with the drawing I provided. The freeze happens with most of my drawings, but a few drawings, without many layers, will not freeze. I suspect that the program chokes somewhere on a long list, at least on older equipment like my computer. I wonder if they tested the problem on old machines.

Tomas Polak

@John Hersey:

 Hi - I have the same problem that "layer" will freeze the program and reported it as a bug. They were not able to reproduce the problem, even with the drawing I provided. The freeze happens with most of my drawings, but a few drawings, without many layers, will not freeze. I suspect that the program chokes somewhere on a long list, at least on older equipment like my computer. I wonder if they tested the problem on old machines.

Hi John,

I am recalling now, that BricsCAD 15.1.21 was crashing on me when trying to open layers with some drawings. After I installed beta version of 15.2. the problem went away - so I think this should be fixed once 15.2 is released.

BTW did any one of you encounter keyboard loosing focus while drawing? Sometimes it happens to me (I think it's usually when I type commands and hit spacebar fast, but I am not sure) that the keyboard suddenly looses focus - I can hit any key (even the Esc key) without any response. The only solution is to click with mouse (any button will do) and then the keyboard works again. I wasn't able to find concrete reason that triggers this problem, but it happens to me quite often.

John Hersey

Thanks Tomas - I look forward to the next release. - I don't know about the keyboard loosing focus, per se, but I have noticed that using the [space] bar to enter a command rather than the [enter] key can cause strange results. For example, if I type "-layer" [space] "set", the 'set' will be ignored and it will be as if I typed nothing after the [space], but if I type "-layer" [enter] "set", the command will run normally. I reported this too and they were unable to reproduce it. It is similar enough to your problem that it might be related. It's hard to describe and so might be exactly the same. 

BTW, if I use "-layer" rather than "layer," the program does not freeze. It appears that it is the Layer page of the drawing explorer that's hanging. If I open the drawing explorer using "style," for example, if will open normally, but if I then hit the "layer" tab, the program will hang with the message "Drawing Explorer is not responding."

Screenshot from 2015-04-21 10:14:58.png

John Hersey

 Example: Here I typed "-layer [space] set [space] [space]" - 'Set' was ignored completely.

Screenshot from 2015-04-21 10:18:31.png

Tomas Polak

Hi John,

I didn't dig deeper into the layers tab bug deeper, since the first thing I was recommended from the Bricsys' staff was to try with V15.2 beta and the problem went away. But I think it's the same problem you're having, let's hope 15.2 will be released soon.

Thanks for pointing out the spacebar instead of enter usage. I tried your way of setting the layer ("-layer [space] set [space]") and I cannot reproduce the problem (I tried with v15.2 and v14).
After that, I tried turning PROMPTMENU=0. When there's no promptmenu, I can reproduce your problem exactly the way you are reporting it. Will you please  report this to your SR (that to reproduce the problem, one needs to turn PROMPTMENU off)?
I found and reported few other problems with keyboard focus when PROMPTMENU is of (this is the way I prefer to work, but it seems most testing goes into working with the default PROMPTMENU on).

The thing with me loosing focus during drawing happens even though I have PROMPTMENU turned on. I will have to do some testing with using just enter insted of spacebar.

John Hersey

 Hi Tomas - thanks for noticing the effect PROMPTMENU has on the space bar. If I turn on PROMPTMENU, the spacebar issue goes away. Too bad I hate the prompt menus, or the problem would be solved. - I have added a note to the bug report. Thanks again for catching it.

Tomas Polak

I dislike the promptmenu too, but I stumbled few times on small problems like yours, which only happen when promptmenu is on, so now I work with promptmenu on until these issues are resolved.

John Hersey

From support ticket: "After more tests, I was able to reproduce this behavior. I will send this to our development team and keep you updated." Strange behavior from *not* invoking the promptmenu.

John Hersey

 Hi Tomas - I've been working with the promptmenu on and now have the dialog loss of focus you mentioned. I can't figure out what action in particular will cause it (in addition to the promptmenu being on,) but will watch as long as I can tolerate the menu. I had not experienced it before, when promptmenu was off. Do you have a bug report on this?

Tomas Polak

@John Hersey:

 Hi Tomas - I've been working with the promptmenu on and now have the dialog loss of focus you mentioned. I can't figure out what action in particular will cause it (in addition to the promptmenu being on,) but will watch as long as I can tolerate the menu. I had not experienced it before, when promptmenu was off. Do you have a bug report on this?

Hi John,
I am not sure I understand correctly. I don't understand "dialog loss". Did you sometimes start to loose keyboard focus (that's what you call "dialog loss") when promptmenu is on?
In my experience, I loose keyborad focus even when promptmenu is on (I was testing this and promptmenu on/off has no effect on this behaviour). I filed few SR where I could specifiy concretely, when keyboard focus is lost, but it happens to me even when I don't know (and therefore cannot reproduce) the reason.
One of those problems I nailed down (and reported) is this:
1] turn dynamic input on (doesn't metter if promptmenu is on/off)
2] start drawing line and pick first point with mouse
3] pan viewport with middle mose button
4] now try to input number through keyboard - it's not possible, keyboard focus is lost

I think all of these have the same culprit, so I hope once these are fixed, even the bad behaviour we cannot reproduce will go awaya.

John Hersey

Hi Tomas -- By "dialog loss of focus" I meant what you call "keyborad focus."

Yes, I sometimes lose keyboard focus since turning on the promptmenu. I never had the problem before, until I turned the promptmenu on because of the spacebar issue. I haven't figured out the exact actions that make it happen. -- John

Tomas Polak

John,
so you are the first person who could reproduce the same problem I am having. Although it happens even with promptmenu turned off to me. I tried fiddling with Bricscad, but found no concrete reason. One thing I was thinking of is, if it's not ditribution-specific. I guess most testing and most users are on Ubuntu. I am using Fedora (with Gnome DE, but I also tried MATE with the same problem) and during my short testing with Ubuntu, I didn't encouter this problem (but it was really just a short test - so I have no certainty). Which distribution are you using?
Let me please know, if you find any more information about this problem, since I ran out of ideas how to troubleshoot this.
Tom

John Hersey

Hi Tom,

I use Linux Mint Debian. I prefer regular Mint, but the new versions of both Ubuntu and Mint don't see my hard drive and I'm not interested in spending any more time figuring out why not.

Regarding the loss of focus, it usually happens mid-command. For example, if I were drawing a polyline and wanted to zoom in close to hit a specific end point, I might "pline 'z 'end' ," the keyboard might stop after the 'e' in end. Also noticed this with the 'dim' commands, and it seems to be when it's expecting a coordinate input and I type an overriding snap first. It does not do it every time and it might not be limited to those conditions. Sorry to be so vague.

John

John Hersey

 Oops - the post did not show what I typed. I must have used some sort of code.

What looks like "pline  'z  'end'  ," was supposed to be pline [point] [point] 'z [point] [point] end [point] except I used < instead of [ brackets. And the keyboard would lose focus after the e in end, for example.

Tomas Polak

Hi John,
it looks like we are having the same problem, so it's not distro or DE specific. As you said, one can only describe it in a vague form, because there's no pattern in this behaviour.