wxWindows 2.4.1
Julian Smart
or shortly thereafter, so all testing of the 2.4 branch
will be very welcome, as would any suggestions for must-have
bug-fixes too.
Thanks,
Julian
=========================================================================
Julian Smart mailto:julian...@btopenworld.com
3 Water Street, Stamford, www.anthemion.co.uk
Lincs, U.K., PE9 2NJ +44 (0)1780 765976
StoryLines: story structuring www.storylinescentral.com
HelpBlocks: HTML help authoring www.helpblocks.com
DialogBlocks: cross-platform dialogs www.anthemion.co.uk/dialogblocks
=========================================================================
chris elliott
chris
Dimitri wrote:
> At 11:38 6/1/2003, Julian Smart wrote:
>
>> We're planning on making a release this weekend (8th June)
>> or shortly thereafter, so all testing of the 2.4 branch
>> will be very welcome, as would any suggestions for must-have
>> bug-fixes too.
>
>
> I'll do the usual compile-all-samples-with-msvc test.
>
> I don't care much about backwards (binary) compatibility, but I recall
> something about the current wxWindows 2.4.1 DLL not working with the
> 2.4 DLL release (With Borland), causing an immediate crash. Did someone
> dare to look into it?
>
> Regards,
> Dimitri
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-un...@lists.wxwindows.org
> For additional commands, e-mail: wx-de...@lists.wxwindows.org
>
Julian Smart
>So if it's not binarally compatable and we change the name the developer
>would have to recompile anyway, and if it is binarally compatable the
>developer would have to rename the dll anyway.
OK, thanks!
Hajo Kirchhoff
Is an app-developer supposed to _rename_ the DLL before distributing his
application? Then I agree, adding the micro number gives no advantage.
OTOH, if it is ok to distribute a wxMSW24.DLL, then adding the micro number
for versions that are no longer binary compatible is a MUST IMHO. Otherwise
an application redistributing a newer version of the wxWindows DLL will
break installed application using the older version. Thats very bad: You
install a new application and suddenly your old applications no longer run.
The reason is of course that Windows will load whichever wxWindows DLL
comes first in the search path and - worse - if a DLL with that name is
already in memory, it will not load it again from a different path.
So whats the policy? Rename wxWindows DLLs before distributing?
Hajo
Julian Smart
>Julian Smart <julian...@btopenworld.com>:
> > We're planning on making a release this weekend (8th June)
> > or shortly thereafter, so all testing of the 2.4 branch
> > will be very welcome, as would any suggestions for must-have
> > bug-fixes too.
>
>reports about bugs under SF numbers/IDs:
>
>demos/bombs crash - #748143
>contrib/samples/fl/fl_sample crash - #748159
>contrib/samples/fl/fl_demo crash - #748171
>contrib/samples/ogl/... - #748226
>
>I have also added "Not a bug" entry - #748181
>
>tomorrow I will check regular samples and utils
Many thanks, this is very useful. I'll have a look at
the bug reports.
Julian Smart
>>I never tried this but there is separate download for free debugger probably
>>aplicable to free compiler at
>>http://www.borland.com/products/downloads/download_cbuilder.html
>
>yes the debugger works well providing
> 1) you always put a breakpoint on MyApp::OnInit
> 2) use this breakpoint to set one in MyFrame::MyFrame
>You can then set the breakpoints wherever you like
Aaagh, not the DOS-like Turbo Debugger? I've tried it in
the past but it's a complete nightmare in my experience.
So unfortunately I won't be trying to debug those BC++ bugs,
sorry...
Julian Smart
>fl_demo2 crashes in rowlayoutpl.cpp, line 459, where it is dividing by zero
>
>if ( haveSquished )
> unit = freeSpc / pcntSum;
>
>pcntSum is made zero in the preceeding few lines.
Aha, thanks for tracking that down.
I've committed a fix to simply set pcntSum
to 1.0 if it's zero. Not a very intelligent
fix but it's better than crashing.