Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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

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.

Comments

  • 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
  •  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 - 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.
  • 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."
    imageScreenshot from 2015-04-21 10:14:58.png
  •  Example: Here I typed "-layer [space] set [space] [space]" - 'Set' was ignored completely.
    imageScreenshot from 2015-04-21 10:18:31.png
  • 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.
  •  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.
  • 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.
  • 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.

  •  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 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.

  • 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
  • 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
  • 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


  •  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.
  • 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.
This discussion has been closed.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam