On Sun, 22 Jun 2008, Szakáts Viktor wrote: Hi Viktor,
> I see, in fact I also have the window painted then > repainted in new size. Since this is a generic problem > (albeit not a huge one IMO), we may think about some > generic ways to avoid it (without special hacks that is). There are also other reasons to have such functionality, f.e. program which is usually executed as service working in background but when it cannot finished it's job then it opens console window switching to interactive mode. > 1) or instance the window gets created only on the > first actual screen access, or something similar > (this may slow down screen methods a bit). GTXWC has such functionality. The console window is shown after 1-st screen update. It's important functionality because application which uses GTXWC can be executed without active X server and inform user using stdout()/stderr() functions that it will not work in such mode or make other alternative actions. > 2) Or we might say that any font type, size, etc > changes are displayed on screen on the first SetMode() > call only. This would effectively reduce flickering > to only one repaint per startup (or layout change). > This is already a problem, where only one specific > (but not well documented) hb_gtInfo() call is > initiating a repaint. The problem is that GT driver have to be initialized at startup before any user code is executed. It means that we have to inform the GT driver in other way that it should not show console window immediately. ANNOUNCE HB_NOSTARTUPWINDOW effectively resolves this problem. I do not see anything wrong with it. Probably the only other solution is adding RT support to change active GT driver so application can be linked with GTNUL ad default GTD and later switch to other RDD depending on RT conditions. This will need some deeper modifications I wanted to add working on multi window API also with some other ones. Anyhow it's not sth what I will want to start before final 1.0 so now I suggest to restore HB_NOSTARTUPWINDOW for people which strongly need it for existing programs. Later we will think about sth much more elegant. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
