[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gambas-devel
Subject:    Re: [Gambas-devel] Early auto-instance
From:       tobi <tobias () gambas-buch ! de>
Date:       2012-05-12 22:36:21
Message-ID: 20120512223621.GP606 () aurora
[Download RAW message or body]

On Sun, 13 May 2012, Beno=EEt Minisini wrote:
> Le 13/05/2012 00:07, tobi a =E9crit :
> >
> > 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 setting=
s (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=EEt 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
> =


My last commit was relatively long ago. I changed some things and will cont=
inue 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 w=
hole 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 a=
s 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 Windo=
w 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


---------------------------------------------------------------------------=
---
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-devel
[prev in list] [next in list] [prev in thread] [next in thread]