[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #1679

Trouble Report Files:

No files

Trouble Report Comments:

	Name/Time/Date	Text
	#1  d.zimmer 21:46 May 14, 2007	Borderless windows on WIN32 (WindowsXP) do not appear on the taskbar. example: int main(void) {   Fl_Window w(0, 0, 640, 480, "borderless");   w.border(0);   w.show();   return Fl::run(); } This is the result of assuming they are used for menus, and adding "styleEx |= WS_EX_TOOLWINDOW" in the function Fl_X::make() found in Fl_win32.cxx In order to avoid this, the code needs to differentiate. This is one possible solution: >>change to Fl_X::make() in Fl_win32.cxx     switch (fake_X_wm(w, xwm, ywm, bt, bx, by)) {       // No border       case 0: if(w->type() == FL_MENU_WINDOW) {                 styleEx |= WS_EX_TOOLWINDOW;         }         style |= WS_POPUP;         break; >>change to Fl_Window.H #define FL_MENU_WINDOW 0xF2 >>change to Fl_Menu_Window.H   Fl_Menu_Window(int W, int H, const char *l = 0)     : Fl_Single_Window(W,H,l) { type(FL_MENU_WINDOW); image(0); }   Fl_Menu_Window(int X, int Y, int W, int H, const char *l = 0)     : Fl_Single_Window(X,Y,W,H,l) { type(FL_MENU_WINDOW); image(0); } A quick search of the existing usage of FL_WINDOW and FL_DOUBLE_WINDOW, seems to indicate that adding FL_MENU_WINDOW would not have any side-effects, although this has not been properly tested. Don.
	#2  matt 03:26 May 16, 2007	Thank you for the STR and the provided patch. I would like to postpone this though to the next version because it does change the behavior for other tooltip-like windows as well. I suggest that we will have a true API for different kinds of window usages then.
	#3  d.zimmer 18:13 Jan 18, 2008	As a follow-up, I recently needed for menus to have a backing store on win32 to avoid redrawing a complex OpenGL scene... this would also happen for a sub-menu rollover, which was intolerable.  Instead of using type() as above, I decided to go with xclass() which seemed more appropriate: Fl_Menu_Window.H   Fl_Menu_Window(int W, int H, const char *l = 0)     : Fl_Single_Window(W,H,l) { xclass("FLTK_MENU"); image(0); }   Fl_Menu_Window(int X, int Y, int W, int H, const char *l = 0)     : Fl_Single_Window(X,Y,W,H,l) { xclass("FLTK_MENU"); image(0); } Fl_win32.cxx   wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC | CS_DBLCLKS;   if(!strcmp(class_name, "FLTK_MENU")) wc.style |= CS_SAVEBITS; If ever y'all get around to tweaking window behaviour on win32, then I would vote +42 on this one. Don.
	#4  AlbrechtS 10:36 Mar 29, 2008	Note: when reviewing the STRs for FLTK 1.3, I found that STR #767 is related, although it requests a different combination of window attributes. For implementation, these two STRs should be considered together. STR #767: http://www.fltk.org/str.php?L767
	#5  AlbrechtS 09:38 Dec 27, 2012	FWIW, meanwhile (in FLTK 1.3 and later) we have: int Fl_Window::menu_window() that can be used to test whether a window is a menu (window). This would simplify the proposed patch and get rid of having to set a specific window class for menus - although that could be useful as well, maybe...

[ Return to Bugs & Features | Post Text | Post File ]