These changelogs reflect the history of all files in the Subversion repository. The changelog has been generated at 2015-02-27 00:18:01

Select Changelog:

FileZilla 3, FileZilla,
FileZilla Server, wxWidgets

Changes per page:

25 50 100 250 500 1000 2000

Changelog for wxWidgets (70435 changes):

2015-01-16 03:39 VZ, revision 78372

Fix typo in wxSOCKET_NOWAIT_WRITE description in the manual. Don't contradict ourselves. Closes #16779.

2015-01-16 03:39 VZ, revision 78371

Fix checks for WXWIN_COMPATIBILITY_3_0: use #if, not #ifdef. The deprecated methods were always available as WXWIN_COMPATIBILITY_3_0 is always defined, we need to check its value and not its definedness. Closes #16782.

2015-01-13 18:05 JS, revision 78370

Bullet no longer gets the attributes from the first object in the list paragraph, so we can control it via paragraph attributes.

2015-01-13 17:41 AW, revision 78369

Fix using WXWIN_COMPATIBILITY_3_0 in conditional blocks in wxPG code. Check the value of WXWIN_COMPATIBILITY_3_0 instead of checking whether it is defined.

2015-01-12 21:37 AW, revision 78368

Preserve alpha channel flag when rescaling bitmap in wxPGProperty::SetValueImage (when wxUSE_IMAGE == 0). Rescaled bitmap must have the same alpha channel flag as the source bitmap flag in order to be properly displayed.

2015-01-12 21:32 AW, revision 78367

Let system decide about required depth of rescaled bitmap in wxPGProperty::SetValueImage. There is not necessary to fix the color depth - everything is determined internally when converting wxImage to wxBitmap.

2015-01-12 21:29 AW, revision 78366

Sanity check regarding DC in wxPropertyGrid::OnComboItemPaint Ensure that wxDC used by drawing functions in wxPropertyGrid::OnComboItemPaint is valid.

2015-01-12 21:23 AW, revision 78365

Don't attempt to draw element-specific bitmap when drawing wxPGChoices element inside the control field of wxEnumProperty with wxPGComboBox. The only bitmap which can be drawn in the control field is a "general" value bitmap (assigned to the property). Closes #16781

2015-01-11 23:49 VZ, revision 78364

Fix selection of items inserted in virtual generic wxDataViewCtrl. Call wxSelectionStore::OnItemsInserted() explicitly instead of just using our UpdateCount() to update the count of items managed by the selection. This needs to be done to ensure that the newly added items have the correction selection, i.e. are always unselected, as previously this wasn't the case: if wxSelectionStore was in the "selected by default" state as it happened e.g. after selecting all the items in the control, the new items also ended up being selected.

2015-01-11 23:49 VZ, revision 78363

Fix selection in virtual generic wxDataViewCtrl after deleting items. The number of items managed by selection was first decremented by our own UpdateCount() and then, again, by an explicit call to wxSelectionStore:: OnItemDelete(), which resulted in the selection ending up in an invalid state. Fix this by not calling UpdateCount(), and hence wxSelectionStore:: SetItemCount(), at all, just OnItemDelete() is enough.

2015-01-10 10:13 SC, revision 78362

removing overridden ProcessIdle, reverting that part of r75289

2015-01-09 04:30 VZ, revision 78361

Send deactivation events to MDI children frame in wxMSW too. For some reason, the code only forwarded activation events to the current MDI child, but not the deactivation ones. And even though this was literally always the case (the check for the event being the activation one is there since r9), it is clearly wrong as the focus restoring code in wxTopLevelWindow in wxMSW doesn't work if the focus hadn't been previously saved. This fix hopefully completes the changes started by r78340 and r78341 and ensures that the focus is always properly restored to the last focused window inside an MDI child.

2015-01-09 04:30 VZ, revision 78360

No changes, just fix a slightly misleading comment in wxMSW focus code. DefWindowProc() never preserves the focused window actually, whether we use WM_NEXTDLGCTL (which is only handled by DefDlgProc() anyhow) or not.

2015-01-09 04:30 VZ, revision 78359

Make specifying minimal size for "unknown" XRC controls work. At least since the changes of r44456 (see #8378), minimal size specified in the XRC for unknown controls didn't have any effect as it was set on wxUnknownControlContainer itself and was overridden by the subsequent call to SetSizerAndFit() which reset the minimal size to the best size of the control contained in it, meaning that it was impossible to make this contained control bigger by specifying min size greater than its best size in the XRC. Fix this by honouring both the min size of the container and of the control contained in it (and do the same thing for the max size for good measure). To avoid not totally obvious interaction of overriding GetMinSize() and DoGetBestClientSize() with sizer code, also position the child control manually instead of using a sizer for it, it's an overkill for such a simple case anyhow.

2015-01-09 04:30 VZ, revision 78358

Make generic wxDataViewCtrl initially usable from keyboard. This control doesn't react to the keyboard at all if it doesn't have a current row and as it doesn't have it initially, it means that there is no way to do anything with the control without clicking it with the mouse first. Fix this by giving it a current row, if possible, whenever it gains focus.

2015-01-09 04:29 VZ, revision 78357

Always invalidate wxStaticText best size after changing its label. wxST_NO_AUTORESIZE style only affects whether the control is actually resized when its text changes, but its best size should always change, so that if the window containing it is explicitly relaid out the size does change. Moreover, in wxMSW and wxOSX the best size was never invalidated at all when the label was ellipsized, so it was never updated for them, preventing, for example, comparing the best size with the current one to check if the text is effectively ellipsized (and so needs to be shown in a tooltip, for example). Fix this by calling InvalidateBestSize() unconditionally, this should make these ports behave in the same was as wxGTK already did.

2015-01-08 15:11 VZ, revision 78356

only flush a client dc if it was not inheriting the native CGContextRef from an outside paint context, fixes #16334

2015-01-06 21:20 VZ, revision 78355

Fix wxBitmap conversion to wxImage in 64-bit wxOSX builds. Don't assume that sizeof(long) == 4, this is just wrong. Closes #16770.

2015-01-06 21:08 VZ, revision 78354

Fix wxBitmap conversion to wxImage in 64-bit wxOSX builds. Don't assume that sizeof(long) == 4, this is just wrong. Closes #16770.

2015-01-06 08:12 MAR, revision 78353

Added new ctor for wxBitmap using wxCursor for wxQT (similar to wxGTK) This is the implementation that should had been included in r78348

2015-01-05 13:49 TIK, revision 78350

On wxMac, modal event loops avoid deleting pending objects. Hide the text control after editing a label in the generic tree control so it does not remain visible e.g. if the tree control is used in a dialog.

2015-01-05 13:48 TIK, revision 78349

On wxMac, modal event loops avoid deleting pending events. Hide the text control after editing a label in the generic tree control so it does not remain visible e.g. if the tree control is used in a dialog.

2015-01-04 04:51 MAR, revision 78348

Added new ctor for wxBitmap using wxCursor for wxQT (similar to wxGTK)

2015-01-04 03:49 MAR, revision 78347

Added missing ctor for wxBitmap using wxIcon for wxQT (taken from wxOSX)

2015-01-03 21:45 VZ, revision 78346

Fix wxFileDialog::GetFilterIndex() when opening files in wxOSX. Update m_filterIndex in the "opening" case, just as we already did in the "saving" one (see #13158 and r67550). Closes #16764.