Liberty BASIC Community Forum
« window opened in a sub: weird resize, crash »

Welcome Guest. Please Login or Register.
Nov 17th, 2017, 10:33pm


Rules|Home|Help|Search|Recent Posts|Notification

Problems installing Liberty BASIC? Read the Vista/Win7 Installation FAQ
Looking for a categorized List of Bug Reports? Visit the Liberty BASIC Bug Tracker

« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 thread  Author  Topic: window opened in a sub: weird resize, crash  (Read 195 times)
tsh73
Board Moderator

member is offline

Avatar

Anatoly (real name)


PM

Gender: Male
Posts: 1686
xx window opened in a sub: weird resize, crash
« Thread started on: Nov 11th, 2012, 07:54am »

Looks like two (may be realated) bugs.
If run as is, then window resized, graphicbox jumps to a new position - corresponding to window coordinates, no less!
If uncomment creating of another variable, it dies on resize.

Code:
nomainwin
    CALL OpenJustText

    WAIT

    SUB OpenJustText
        WindowWidth = 300
        WindowHeight = 200
        UpperLeftX = 150
        UpperLeftY = 100

'x=100  'uncommenting this makes it die on resize

        a=10
        b=20
        c=30
        d=40

        graphicbox #JTWin.SB, a,b,c,d
        'somehow, after resize,
        'it repositions graphicbox with values of UpperLeftX, UpperLeftY etc

        open "Please try resize this window" for window as #JTWin
        #JTWin "trapclose JTQuit"
    END SUB

    SUB JTQuit handle$
        close #JTWin
        if JT.JumpIsOpen=1 then close #JTJump
        end
    END SUB
 
« Last Edit: Nov 11th, 2012, 07:54am by tsh73 » User IP Logged

damned Dog in the Manger
stefanhes
Guru
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 723
xx Re: window opened in a sub: weird resize, crash
« Reply #1 on: Nov 11th, 2012, 3:51pm »

My thoughts (5 cent):

After opening a sub, all what you do is supposed to be LOCAL.
When closing the sub, all LOCAL stuff should be garbage and the window shouldn't even be there anymore ....
(but I see it still is, but perhaps its parameters space has been released)
User IP Logged

http://www.soundofanimals.com
http://sincosin.com
Brandon Parker
Board Moderator

member is offline

Avatar




PM

Gender: Male
Posts: 1118
xx Re: window opened in a sub: weird resize, crash
« Reply #2 on: Nov 11th, 2012, 10:48pm »

on Nov 11th, 2012, 3:51pm, stefanhes wrote:
My thoughts (5 cent):

After opening a sub, all what you do is supposed to be LOCAL.
When closing the sub, all LOCAL stuff should be garbage and the window shouldn't even be there anymore ....
(but I see it still is, but perhaps its parameters space has been released)


Anatoly is correct. There does seem to be a bug with this where the graphicbox position/ dimensions are not being done correctly, but the bug is only present when you use variables as the position/ dimensions which are no longer visible in scope. I suspect this will happen for any native control in LB/ JB. This stems from the undocumented feature wich allows for the correct resizing of controls when variables are used for their positions/ dimensions instead of hard coded numbers. The user only has to change the variable value and send the refresh command to the window and the control with the variables as it's position/ dimensions will change relocate/ resize according to the variables' values. The jumping of the graphicbox is after the local variables (a-d) are discarded is peculiar. Where the values for the position/ dimensions are coming from I can not know exactly, but I would assume the values to always be erroneous vestigages/ other variables (visible to the current scope) within LB's memory buffer based on some pointers that might be dangling ..... sort-of. At least that the way I can see it happening.

The problem is eliminated if the variables are changed to Global, array elements, or structure elements.

There are two problems....
  1. First - Where are the values coming from during the resize event when the variables used to create the graphicbox are local to the subroutine?
  2. Why does creating another local variable within the subroutine (x) cause LB to crash to the desktop (even in debug) with the "Virtual Machine Stack Overflow" error (I received the "Collection Out of Bounds" error once during testing)? (This doesn't happen if the other variables are global in scope.)


As far as the window creation within a subroutine goes; creation of windows within subroutines is a nice feature and I am greatly thankful for this. The fact that the subroutine has completed should never "destroy" the window. This allows for multiple windowed programs and easily implemented program flow control. In fact you can create the same window over and over again if you implement the window creation code correctly utilizing the Maphandle command (see helpfile example).

The work-a-round for this would just be to simply always use a variable type with global scope if you are going to be creating windows withing subroutines that have resizable features.

You could use a structure for a windows properties. Something like this.....
Code:
Struct myWindow, xCoordinate As long, _
                 yCoordinate As long, _
                 width       As long, _
                 height      As long, _
                 enabled     As long, _
                 visible     As long 


That could be expanded to hold a myriad of things about the window. You could, if you wanted to, use api calls to allocate memory for this structure and set up functions to set/ retrieve all of the values on command (have done this already and it works nicely and quickly as well). This essentially affords a more advanced LB coder the ability to have his own user "type"; not built into the language, but functional either way. I created a demo that set up the functions to mimic the way an OOP language would work; using the structure/ memory allocations as objects which were only accessible if the correct object name was passed.

Sorry for the rambling; I got off on a tangent there.....

My point is just use globaly scoped variables in such instances and all will be well....... ;D


{:0)

Brandon
« Last Edit: Nov 12th, 2012, 06:42am by Brandon Parker » User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
tsh73
Board Moderator

member is offline

Avatar

Anatoly (real name)


PM

Gender: Male
Posts: 1686
xx Re: window opened in a sub: weird resize, crash
« Reply #3 on: Nov 11th, 2012, 11:23pm »

Quote:
My point is just use globaly scoped variables in such instances and all will be well....... grin

Thank you for workaround. I'll relate that to original poster on another basic forum.
User IP Logged

damned Dog in the Manger
tsh73
Board Moderator

member is offline

Avatar

Anatoly (real name)


PM

Gender: Male
Posts: 1686
xx Re: window opened in a sub: weird resize, crash
« Reply #4 on: Sep 19th, 2016, 04:01am »

It looks that if I move "wait" from main program into SUB (just before end sub) fixes theses craches.
But then again, with that you cannot call two functions to create two windows?
User IP Logged

damned Dog in the Manger
Brandon Parker
Board Moderator

member is offline

Avatar




PM

Gender: Male
Posts: 1118
xx Re: window opened in a sub: weird resize, crash
« Reply #5 on: Sep 20th, 2016, 9:58pm »

on Sep 19th, 2016, 04:01am, tsh73 wrote:
It looks that if I move "wait" from main program into SUB (just before end sub) fixes theses craches.
But then again, with that you cannot call two functions to create two windows?


You should never WAIT inside a subroutine!!

{:0)

Brandon
User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
tsh73
Board Moderator

member is offline

Avatar

Anatoly (real name)


PM

Gender: Male
Posts: 1686
xx Re: window opened in a sub: weird resize, crash
« Reply #6 on: Sep 21st, 2016, 01:03am »

Quote:
You should never WAIT inside a subroutine!!

Could you explain me why?
Supposing I have all my event handlers as SUBs
(that means I have no timer, though)
User IP Logged

damned Dog in the Manger
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5560
xx Re: window opened in a sub: weird resize, crash
« Reply #7 on: Sep 21st, 2016, 04:12am »

Since the window created is a global resource it seems obvious now that the variables defining its size are global.

I don't think it matters where you wait, either in the sub or the main program provided you have set all events to have a visible handler. So [branch] label handlers and subs don't mix. But [branch] label handlers within subs work for me. Timers also seem to work best encased in a sub.

Choosing where to wait is more about program flow. If the wait is in the window opening sub my delay never gets called. But waiting in the delay sub allows other events to be handled by subs like resize or close.

Code:
    nomainwin
    global a,b,c,d
    CALL OpenJustText
    CALL Delay 5000
    close #JTWin
    end


    SUB OpenJustText
        WindowWidth = 300
        WindowHeight = 200
        UpperLeftX = 150
        UpperLeftY = 100

        x=100

        a=10 'global
        b=20
        c=30
        d=40
        graphicbox #JTWin.SB, a,b,c,d
        open "Please try resize this window" for window as #JTWin
        #JTWin "trapclose JTQuit"
    END SUB

    SUB JTQuit handle$
        close #JTWin
        if JT.JumpIsOpen=1 then close #JTJump
        end
    END SUB


    SUB Delay ms
        timer ms, [done]
        wait
        [done]
        timer 0
    end sub
 
« Last Edit: Sep 21st, 2016, 04:21am by Rod » User IP Logged

Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5560
xx Re: window opened in a sub: weird resize, crash
« Reply #8 on: Sep 21st, 2016, 05:59am »

Actually I am going to correct my last comments. The code works because there is only one wait in the delay. That was deliberate. But if you code a wait or scan elsewhere there is a danger that the [Done] label will not be found.

So this amended code still has only one wait but it would tolerate other waits because now the timer event is handled by a sub itself.

Put a wait at the end of the colorit sub to see.



Code:
    nomainwin
    global a,b,c,d,flag
    call OpenWindow
    call Delay 5000
    close #w
    end


    sub OpenWindow
        WindowWidth = 300   'these are global
        WindowHeight = 200
        UpperLeftX = 150
        UpperLeftY = 100
        x=100               'this is local
        a=10                'these need to be global
        b=20
        c=30
        d=40
        graphicbox #w.gb, a,b,c,d
        open "Please try resize this window" for window as #w
        #w "trapclose quit"   'handler to quit
        #w.gb "when leftButtonDown colorit"
        'we have opened the window, move on dont wait
    end sub

    sub quit handle$
        timer 0
        close #w
        end
    end sub

    sub colorit handle$,x,y
        if flag then
            #w.gb "down ; fill white"
            flag=0
        else
            #w.gb "down ; fill red"
            flag=1
        end if
        'we have colored it, move on dont wait
    end sub

    sub Delay ms
        timer ms, Done
        wait
    end sub

    sub Done
        timer 0
        call quit handle$
    end sub
 
« Last Edit: Sep 21st, 2016, 06:02am by Rod » User IP Logged

tsh73
Board Moderator

member is offline

Avatar

Anatoly (real name)


PM

Gender: Male
Posts: 1686
xx Re: window opened in a sub: weird resize, crash
« Reply #9 on: Sep 21st, 2016, 07:46am »

Timer event with a sub == bug
http://libertybasicbugs.wikispaces.com/TIMER-sub+as+event+handler

If I make timer fire more then once and try to move (or resize) it, window freeses (like in a bug report)
Code:
    nomainwin
global  num
    global a,b,c,d,flag
    call OpenWindow
    call Delay 1000

    wait
    close #w
    end


    sub OpenWindow
        WindowWidth = 300   'these are global
        WindowHeight = 200
        UpperLeftX = 150
        UpperLeftY = 100
        x=100               'this is local
        a=10                'these need to be global
        b=20
        c=30
        d=40
        graphicbox #w.gb, a,b,c,d
        open "Please try resize this window" for window as #w
        #w "trapclose quit"   'handler to quit
        #w.gb "when leftButtonDown colorit"
        'we have opened the window, move on dont wait
    end sub

    sub quit handle$
        timer 0
        close #w
        end
    end sub

    sub colorit handle$,x,y
        if flag then
            #w.gb "down ; fill white"
            flag=0
        else
            #w.gb "down ; fill red"
            flag=1
        end if
        'we have colored it, move on dont wait
    end sub

    sub Delay ms
        timer ms, Done
        wait
    end sub

    sub Done
        num=num+1
        if num <10 then
            #w.gb "down ; fill ";word$("red green blue yellow cyan", num mod 5+1)
        else
            timer 0
            call quit handle$
        end if
    end sub

 
« Last Edit: Sep 21st, 2016, 07:47am by tsh73 » User IP Logged

damned Dog in the Manger
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5560
xx Re: window opened in a sub: weird resize, crash
« Reply #10 on: Sep 21st, 2016, 09:06am »

I do recall Carl showing us that it could repeat if it was reset rather than allowed to repeat. I assume it is about the program knowing where to return to.

Code:
    nomainwin
    global a,b,c,d,flag,num
    call OpenWindow
    call Delay 1000
    close #w
    end


    sub OpenWindow
        WindowWidth = 300   'these are global
        WindowHeight = 200
        UpperLeftX = 150
        UpperLeftY = 100
        x=100               'this is local
        a=10                'these need to be global
        b=20
        c=30
        d=40
        graphicbox #w.gb, a,b,c,d
        open "Please try resize this window" for window as #w
        #w "trapclose quit"   'handler to quit
        #w.gb "when leftButtonDown colorit"
        'we have opened the window, move on dont wait
    end sub

    sub quit handle$
        timer 0
        close #w
        end
    end sub

    sub colorit handle$,x,y
        if flag then
            #w.gb "down ; fill white"
            flag=0
        else
            #w.gb "down ; fill red"
            flag=1
        end if
        'we have colored it, move on dont wait
    end sub

    sub Delay ms
        timer ms, Done
        wait
    end sub

    sub Done
        timer 0
        num=num+1

        if num<10 then
            call colorit h$,x,y
            call Delay 1000
        else
            call quit handle$
        end if
    end sub


 


I have taken the discussion down a new path. The global variables for a global window resource is a good fix. Whether we have cracked the timer issue or indeed fully understood what is going on remains an issue.
User IP Logged

Brandon Parker
Board Moderator

member is offline

Avatar




PM

Gender: Male
Posts: 1118
xx Re: window opened in a sub: weird resize, crash
« Reply #11 on: Sep 21st, 2016, 8:39pm »

The problem is the program shown in the previous post does the following.
  1. Opens Window
  2. Calls Delay Subroutine
  3. Calls Done Subroutine
  4. Calls Delay Subroutine
  5. Calls Done Subroutine
  6. Rinse and Repeat for the specified number of times
  7. Close Window
  8. End Execution of Code


Basically here it is not causing a problem because the program exits eventually, but Since you are waiting in the Delay Subroutine and then calling the Delay subroutine again from the Done Subroutine you are essentially successively instructing the computer to create a stack or section of memory for each subroutine called. Since the program doesn't exit the subroutines they never get cleaned up; they are essentially still in use. Only when the specified number has been reached does the program exit all of the subroutine calls that were made. This is exactly why it is bad to WAIT in a Subroutine/ Function. These constructs are meant to be pieces of code that are called and completed from the main section/ loop of a program and after completion execution returns to the main section/ loop.

If you change the number of iterations to something like 1000000 and then change the Timer value to 1ms you can then easily observe, via Task Manager, the Commit Size of the program. This is the memory that the program has "touched"(committed). This value should go up to a value and the bounce around said value as the program allocates and frees memory as needed, but you can see that doing it this way only causes the Commit Size to steadily increase over time. Eventually the program could/ would consume all of the available memory.

That's my two cents on why it is bad to WAIT in a Subroutine/ Function.


{:0)

Brandon
« Last Edit: Sep 21st, 2016, 8:42pm by Brandon Parker » User IP Logged

Windows 7 Home Premium 64-bit Intel(R) Quad Core(TM) i5 CPU M 430 @ 2.27GHz 4GB DDR3 RAM
Rod
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Graphics = goosebumps!


PM

Gender: Male
Posts: 5560
xx Re: window opened in a sub: weird resize, crash
« Reply #12 on: Sep 22nd, 2016, 01:27am »

I thought I was exiting all subs. In that case the only thing that should persist is the global content.

I will try and break it.

EDIT:

I ran a million iterations and it did not break but I take your point the memory use did grow.

That said my bad programming should not set the seal on the debate. I think quite a lot of folks wrap popup windows and stuff in a sub and provided external events are managed it is quite acceptable to wait or scan in that sort of code.

Functions I completely agree with, fast data transformations, no event management.
« Last Edit: Sep 22nd, 2016, 06:07am by Rod » User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Rules|Home|Help|Search|Recent Posts|Notification

Liberty BASIC Community Wiki
Wikispaces
Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls