DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current
Run on Mac OS with 2 screens the editor test program.
Move the window to the secondary screen.
Type cmd-R
crash!
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
A. If I position the test/menubar application such that the menubar
is at the bottom of my screen, most of the menus open upwards
so that the
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current
Fix Version: 1.3-current (r9177)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2769
Version: 1.3-current
Fix Version: 1.3-current (r9177)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
I believe the behavior of the Huge menu is correct: this menu is
so big that it can't be displayed entirely upwards,
so it opens downwards, as
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
For the International menu issue:
I believe the solution would be to change line 357 of src/Fl_Menu.cxx
from
if (X scr_x) X = scr_x; if (X
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
@manolo: You might be right, not sure.
My thinking is that the 'Huge' behaves inconsistently
compared to the logic of the other menus.
It
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2770
Version: 1.3-current
I would think that opening the 'huge' menu with its top edge at the
window's top would be bad because it would hide the menu title (huge).
I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Don't want to forget about the discussion last month on fltk.general...
http://www.mail-archive.com/fltk@easysw.com/msg12416.html
Link:
Author: manolo
Date: 2011-11-14 07:15:03 -0800 (Mon, 14 Nov 2011)
New Revision: 9176
Log:
Mac OS: better window positioning on secondary displays at creation.
Modified:
branches/branch-1.3/src/Fl_cocoa.mm
Modified: branches/branch-1.3/src/Fl_cocoa.mm
Author: manolo
Date: 2011-11-14 09:10:28 -0800 (Mon, 14 Nov 2011)
New Revision: 9177
Log:
Fix STR #2769: Mac OS crash during creation of non-modal window on secondary
screen
Modified:
branches/branch-1.3/src/Fl_cocoa.mm
Modified: branches/branch-1.3/src/Fl_cocoa.mm
Author: bgbnbigben
Date: 2011-11-14 17:56:17 -0800 (Mon, 14 Nov 2011)
New Revision: 9179
Log:
Aaaand added a comment to something I've just noticed with the ShapedWindow.
I'll get there one day...
Modified:
branches/branch-3.0/src/fltk3/ShapedWindow.cxx
Modified:
I can think of two approaches to doing this, which I've attached
to STR #2728 http://www.fltk.org/str.php?L2728
Curious which you think is better.. I kinda like (A) the most:
A. Have the test/Makefile automatically generate a
shadow_variables.cxx
file on the fly via a
The fltk3 build is bailing on me right now, with r9175.
This is on WinXP with mingw/Msys.
$ make
=== making src ===
Compiling fltk3/ShapedWindow.cxx...
fltk3/ShapedWindow.cxx: In function `HRGN__*
unnamed::bitmap2region(fltk3::Image*)':
fltk3/ShapedWindow.cxx:66: error: `ALLOC_UNIT' undeclared
Sorry, but I think there's something wrong with this patch. Given the
following file:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
void
make(int x, int y, int w, int h, const char *label)
{
printf(%s: wanted: %d %d\n, label, x, y);
Fl_Window *win = new
On 14/11/11 20:49, MacArthur, Ian (SELEX GALILEO, UK) wrote:
The fltk3 build is bailing on me right now, with r9175.
This is on WinXP with mingw/Msys.
$ make
=== making src ===
Compiling fltk3/ShapedWindow.cxx...
fltk3/ShapedWindow.cxx: In function `HRGN__*
I'm using a Fl_Choice widget which is located at the very
bottom of a fullscreen window.
The issue is that when the list is showing up, it is shown
downward and thus not in the window which makes it
practically unusable. Is there a way to change this behaviour ?
I guess I have to go
Thanks Albrecht and Greg for fixing this issue.
On 11/12/11 17:40, Greg Ercolano wrote:
I think to fix this is probably to /record/ the mouse button
state above the switch(), so that the check at point B isn't
confused by the different state of realtime mouse buttons
FLTK 1.3 svn up to date version...
I changed Fl_Choice.cxx handle method :
case FL_PUSH:
if (Fl::visible_focus()) Fl::focus(this);
J1:
if (Fl::scheme()
|| fl_contrast(textcolor(), FL_BACKGROUND2_COLOR) != textcolor()) {
//v = menu()-pulldown(x(), y(), w(), h(),
Hello,
I experienced crash with a program that calls Fl_Double_Window::flush() too
soon so that the myi pointer is NULL.
I added a global null test in the methode to prevent this case... I think this
should be added to trunk (1.3)
Regards
/**
Forces the window to be redrawn.
\param[in]
On 11/13/11 23:34, Mathieu Peyréga wrote:
I'm using a Fl_Choice widget which is located at the very bottom of a
fullscreen window.
The issue is that when the list is showing up, it is shown downward and
thus not in the window which makes it practically unusable. Is there a way to
change
On 11/14/11 08:26, Greg Ercolano wrote:
On 11/13/11 23:34, Mathieu Peyréga wrote:
I'm using a Fl_Choice widget which is located at the very bottom of a
fullscreen window.
The issue is that when the list is showing up, it is shown downward and
thus not in the window which makes it
21 matches
Mail list logo
