[Gambas-devel] Early auto-instance

[tobi]

On Sun, 13 May 2012, Benoît Minisini wrote:
> Le 13/05/2012 00:07, tobi a écrit :
> >
> > All clear, that's all clear, but: routines in the Window object want to refresh the screen. Screen
> > refresh may be buffered. Buffering is handled via the Screen class that represents the entire
> > screen. I need a valid Screen object to determine the buffering settings (in this example; I can
> > spot input stuff that will go through the Screen class, too, as said in another thread recently).
> >
> > Regards,
> > Tobi
> >
> 
> I guess I don't have the latest source code?
> 
> I meant that you don't need the Screen Gambas object as soon as you 
> split the interface (the Screen object) from the implementation.
> 
> The implementation always exists, even if the Screen default object has 
> not been instanciated yet.
> 
> -- 
> Benoît Minisini
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
> 

My last commit was relatively long ago. I changed some things and will continue as soon as this
issue is corrected... (Do you want to take a look? I would have to commit a totally broken
component)

Formerly, it was like: each Window contained its own buffering settings and a refresh was done by
the Windows themselves so everything was there. That however affected the whole screen. This
behaviour was misleading so I decided to move the buffering settings where they belong: the
Screen class.

I have SCREEN_refresh() and SCREEN_real_refresh() which are just the same as the corresponding
WINDOW_ functions (respecting buffering settings and doing a plain refresh, respectively) that can
be visited in the current revision. Normally, all interface functions call the SCREEN_refresh()
function when they are done to update the screen. It is intended that this function checks for
buffering settings and only update when the Screen is unbuffered. If there is no Screen, the
function cannot work. Hence my proposition to include a parent Screen which can be passed as an
argument to the SCREEN_refresh() routine.
But if I do so, the parent Screen must be a mandatory argument to the Window constructor to ensure,
it already exists and consequently, I can say bye-bye to the auto-creatable Window...

I hope to not be so confusing this time.

Regards,
Tobi