locked
SmallBasic 0.8 Bugs RRS feed

  • General discussion

  • SmallBasic crashes if you attempt to highlight lines of code by dragging the mouse within the Line Number column.
    Sunday, February 28, 2010 12:21 PM

All replies

  • Hi!

    I don't get this bug. Anybody else?
    Wednesday, March 3, 2010 10:29 AM
  • Yes,

    1] Open a SmallBasic file.
    2] Move the mouse over some of the line numbers in the left hand side (slightly grey column)
    3] Left click and hold the mouse button down - like selecting text
    4] Move the mouse from the line numbers into the main window
    Wednesday, March 3, 2010 9:12 PM
  • More an interface/n00b issue than a Bug this one....

    If a user happens to have SmallBasic open and Maximised,
    and has their code window positioned so that the bottom of it is below the bottom of the screen,
    and then resizes their code window by dragging from the top of its titlebar,
    and drags their mouse down onto the windows taskbar
    and lets go of the mousebutton...

    ... then there is no way to get the code window back again.

    Note: the above issue also applies when resizing off the left and right edges.


    There is a workaround though...

    As you cannot 'unselect' a code window, it still has focus even though you can't see it.
    Just click 'Save As' and give it a name.
    Then click 'Open' to open the file, and it will be positioned back in view.

    Note, if you have other code windows open as well as the one that's disappeared off the screen, you will have to save/close them all first, then do the 'save as' workaround on the hidden one.


    Admittedly, this 'bug' process is rather convoluted, but I thought I'd mention it.
    Tuesday, March 9, 2010 12:03 AM
  • I'd also like to flag the following (from litdev) as a bug. 

    I'm classing it as a bug because an event handler that only effectively allows a flag to be set is fairly useless. It would be better to be a property of a keyboard class. Actually, I'm not sure why there isn't a keyboard class. All programmers need to learn the differences between input, processing and output, therefore all input devices should have their own class and it goes against any standard logic for keyboard events to be part of the graphics/textwindow properties.

    PS. An early fix to the highlighting-using-line-numbers-crashes-smallbasic bug I posted earlier would be very much appreciated. I have lost a number of blocks of code now due to that problem!

     

    Vitexikora,

    You have stumbled over an important issue with SmallBasic which may be a bug.  It took a bit of playing to work this out!

    Basically you cannot start a subroutine that has moving shapes from inside an event subroutine.

    The following fails to work properly:

    GraphicsWindow.KeyDown=OnKeyDown

    Sub OnKeyDown
      illusion4()
    EndSub

    The following works:

    GraphicsWindow.KeyDown=OnKeyDown

    start = 0
    While ("True")
      If (start = 1) Then
        illusion4()
        start = 0
      EndIf
      Program.Delay(100)
    EndWhile

    Sub OnKeyDown
      start = 1
    EndSub

    This seems to also be the case for the Fremy Control button events.

    So, you need to set a flag from the event call, and use this flag to control the program from a Main Loop. 

    This is a recurring theme - do all the main work in the main program loop - and just use events to set control flag variables . 

    This is extended here to do not call subroutines that do any animation (work) directly from an event .

    Monday, March 29, 2010 12:07 PM
  • I believe i have found a minor annoyance really: NFC273

     

    when you set canResize to false then the windows becomes larger than it actually is set to by about 10px. Its annoying me in one of my little games where i need to draw a grid and the lines just aren't long enough when set to the same size as the window. Granted i can just set them a little bit longer but i expect them to be long enough!

    I think this may only be in Windows 7 with aero enabled as on the XP machine i was playing with i didn't seem to have this issue. So I ran it with aero off and it seemed to be long enough ...

    Thursday, April 1, 2010 12:07 AM
  • The size setting problem happens to me in Vista (I havent tried it in Windows 7) but doesn't happen in WinXP.  Was happening in SM 0.7 too.
    Friday, April 2, 2010 7:37 PM
  • Can also confirm the sizing issue on Vista x64. Can't test on XP at the moment.

    This shows it clearly - just click the mouse on the graphicsWindow...

     

    GraphicsWindow.Height = 300
    GraphicsWindow.Width = 300
    Shapes.AddLine(0,50,300,50)

    While Mouse.IsLeftButtonDown="False"
      Program.Delay(100)
    EndWhile

    GraphicsWindow.CanResize = 0

    Saturday, April 3, 2010 2:19 PM
  • Hello everybody.

    Let me explain my issue:

    Let's assume I have a Sub-EndSub block that does something in my program.

    Then, I want to write another Sub-EndSub, but I write it ABOVE the existent Sub-EndSub block. In this situation, the "Intellisense" feature does not detect the tokens like "to" (for the For loop"), or the "EndSub" to close the Sub block, or the "Then" for the "If" block, and so on.

    This issue does not appears if i write new Sub-EndSub block ALWAYS under the previous one.

    Don't know if i've explained enough... sorry.

    If you want, i can send screen captures...

     

    Thank you.

    Amado. 

     

     

    Friday, April 9, 2010 10:35 AM
  • The same thing happens to me. But I never thought anything of it.

    Friday, April 9, 2010 10:56 PM
  • Well, good to see I'm not alone :-)

     

    Maybe smallbasic developers can take a look at this...

    Saturday, April 10, 2010 8:55 AM
  • Hi all,

    I have the best bug - simply hold Shift + 2xKeyNextToBackspace(ˇ)

     

    Monday, June 14, 2010 6:32 AM