STR #1679

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]

STR #1679

Application:FLTK Library
Status:5 - New
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:2 - Specific to an operating system
Summary:Borderless windows on WIN32 do not appear on the taskbar
Created By:d.zimmer
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 d.zimmer
21:46 May 14, 2007
Borderless windows on WIN32 (WindowsXP) do not appear on the taskbar.


int main(void)
  Fl_Window w(0, 0, 640, 480, "borderless");
  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;

>>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.

#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(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); }

  if(!strcmp(class_name, "FLTK_MENU")) |= CS_SAVEBITS;

If ever y'all get around to tweaking window behaviour on win32, then I would vote +42 on this one.

#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:
#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...
bottom left image   bottom right image

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


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.