Changelogs

Overview

These changelogs reflect the history of all files in the Subversion repository. The changelog has been generated at 2016-05-09 08:38:04

Select Changelog:

FileZilla 3, FileZilla Server,
Legacy FileZilla 2, Legay FileZilla Server

Select page:

[] [1 713 1425 2137 2138 2139 2140 2141 2367 2592 2818] []

Changes per page:

25 50 100 250 500 1000 2000

Changelog for wxWidgets (70435 changes):

2002-09-05 19:36 RD, revision 16990

some tweaks for LINK_LEXERS

2002-09-05 16:15 JS, revision 16989

Applied patch [ 603858 ] wxTextCtrl text alignment patch Benjamin I. Williams This patch implements three new flags for the wxTextCtrl control. The flags are wxTE_LEFT, wxTE_CENTRE, and wxTE_RIGHT. These flags can change the way text is aligned inside an edit control, which is useful when the user is editing numbers or dates. At Vadim's recommendation, the patch implements the alignment flags so they are equal to the corresponding wxALIGN_* value. wxTE_LEFT is actually 0x0000, and is just a place holder. wxTE_CENTRE is equal to wx_ALIGN_CENTER_HORIZONTAL (0x0100), and wxTE_RIGHT is equal to wxALIGN_RIGHT (0x0100). I couldn't agree more with this idea. As Vadim pointed out, choosing to set the text alignment flags to the corresponding wxALIGN_* flags has a slight negative side effect: the values 0x0100 and 0x0200 collide with the existing flags wxTE_NO_VSCROLL and wxTE_AUTO_SCROLL. A valid point was raised, however, which stated that the flags would never really be used at the same time, and also that wxTE_AUTO_SCROLL is (possibly) going to be deprecated anyway. While this collision is not really a problem, I didn't like the idea of someone specifying wxTE_NO_VSCROLL and ending up with with a centered text control ! Thus, I chose to move both wxTE_NO_VSCROLL and wxTE_AUTO_SCROLL down to the free bits 0x0002 and 0x0008, respectively. I'll leave the final say up to Vadim and the rest of you whether you want to move these flags down or keep them where they are (with collisions). What truly matters to me is that I can now create text controls with the proper alignment! This patch also updates the documentation.

2002-09-05 16:15 GD, revision 16988

-o flag must be after PIC flag for gcc under HPUX

2002-09-05 14:56 JS, revision 16987

Added #include <ctype.h> since it seems to have gone missing from this file for non-Unicode cases.

2002-09-05 13:59 GD, revision 16986

added -D_REENTRANT for hpux when threads are enabled

2002-09-05 13:54 DW, revision 16985

Fix for child window positioning

2002-09-05 12:42 SC, revision 16984

corrected code for doubles

2002-09-05 12:28 GD, revision 16983

corrected HPUX specific test

2002-09-05 10:54 VZ, revision 16982

fix Union(empty rect) bug

2002-09-04 22:17 VS, revision 16981

compilation fix for wxUSE_WCHAR_T=0

2002-09-04 22:07 VS, revision 16980

use own mutex for region iterator locking, not gui one

2002-09-04 22:07 VS, revision 16979

why the heck was the flag changed to T from Theme?! Broke my makefiles...

2002-09-04 22:07 VS, revision 16978

compilation fix for wxUSE_WCHAR_T=0

2002-09-04 22:07 VS, revision 16977

added watmgl.t to Makefile

2002-09-04 22:06 VS, revision 16976

whoever added mdig.cpp forgot to update the makefiles

2002-09-04 16:42 MBN, revision 16975

Missing #include

2002-09-04 15:06 VZ, revision 16974

should fix Unicode build for BC++ 5.3

2002-09-04 15:04 VZ, revision 16973

don't use -mthreads switch if the compiler doesn't support it

2002-09-04 14:56 VZ, revision 16972

make --static default if configured with --disable-shared

2002-09-04 14:30 VZ, revision 16971

use standard colour for the selected tree item text as well as background

2002-09-04 14:21 VZ, revision 16970

mention that wxBase builds with BC++ now

2002-09-04 13:50 VZ, revision 16969

fix crash if Delete menu command is used twice

2002-09-04 13:45 VZ, revision 16968

fix wxCheckListBox which was completely broken by the Unicode changes

2002-09-04 13:39 DW, revision 16967

For OS/2

2002-09-04 13:16 VZ, revision 16966

generic status bar now: 1. works correctly (handles negative widths according to the docs/MSW/Univ) 2. has shorter and simpler GetFieldRect() implementation 3. ... which is also more efficient (pixel widths are cached)

Select page:

[] [1 713 1425 2137 2138 2139 2140 2141 2367 2592 2818] []

Imprint