The /M flag must be changed for *all* linked modules. It must be the same in
each and every module that you link. If you change the flag, you must make sure
that FLTK and all other modules are build from scratch, or you will get exactly
the heap corruption that you described.
We chose the /M
Here what I just did to reproduce:
Downloaded latest r9631;
Changed "code generation" to /MTd
for hello, fltkdll, fltkjpeg, fltkzlib, fltkpng
Explicitly changed it to /MTd for file jmemobs.c from JPEG
Changed project reference for hello to fltkdll
Removed fltkd.lib from link
changed subsystem
Hmm, Mikhail, it works absolutely correctly without any errors on my system
(Windows Seven 64, VC2010 Express, Debug, latest svn rev 9631).
I'm afraid it's problem with your machine only. Which version of FLTK do you
use? Do you use something else? Be sure you don't mix headers and .lib files
fr
Hello Nikita,
This is happens in Debug build. It's actually
"Debug Assertion Failed" showing that heap is
corrupted. Stack is not useful. Going step by step
I found that it happens after ~Fl_Window();
xclass in Fl_Window is set to NULL.
The program is here:
#include
#include
#include
//#incl
> If you compile "hello" example and add delete window
> after Fl::run() you will get a crash under windows.
> At least I got it.
Hello, Mikhail. I'm sorry but I don't understand where you found the problem
with deleting of window. I have written simple example and didn't see any
errors, all wor
On 06/29/12 10:17, Matthias Melcher wrote:
> I think that it is a mistake. Even though i show up using Blame.
> Makes no sense to me and should be xhanged back. It may have been a
> search/replace error.
Cool, I'll apply the fix, but think I'll wait a bit to see if everyone
else a
I hope I am not so stupid as someone can think.
If you compile "hello" example and add delete window
after Fl::run() you will get a crash under windows.
At least I got it.
My trivial example was:
main() {
Fl_Window window(340,180);
}
~Fl_Window() gets called when variable goes out of scope.
I
I think that it is a mistake. Even though i show up using Blame. Makes no sense
to me and should be xhanged back. It may have been a search/replace error.
Greg Ercolano schrieb:
>Does anyone remember why FL_WHITE was changed from colormap #7 (fltk
>1.1.x)
>to colormap #255 (in fltk 1.3.x)?
>
Does anyone remember why FL_WHITE was changed from colormap #7 (fltk 1.1.x)
to colormap #255 (in fltk 1.3.x)?
Just curious.
Seems this changed happened in STR#2208
but can't tell from the comments on the commit why it was done.
___
fltk-dev mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2659
Version: 1.4-feature
This patch removes the duplicate code between the different draw_image(),
but having one call the other. This makes sure you get the same feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2659
Version: 1.4-feature
Attached file "fltk-postscript.patch"...
Link: http://www.fltk.org/str.php?L2659
Version: 1.4-featurediff -up ./src/ps_image.cxx.orig ./src/ps_i
11 matches
Mail list logo
