Recent changes to patches

Fixes for 32-bit Windows Builds

2022-12-04T15:59:49.427000Z

For FOX 1.7.81 and Visual Studio 2019.

The 3 patches, in combination with the instructions in the .txt file to update the Visual Studio project configurations, get x86 (32-bit) Windows builds working again.

More specifically, the instructions are enough to build foxdll and to build adie against foxdll.

The changes to FXAtomic.cpp have not been tested.

#14 Consistently use '_WIN32' macro, never 'WIN32'

2022-12-04T15:37:21.140000Z

This patch is for FOX 1.7.81.

Consistently use '_WIN32' macro, never 'WIN32'

2022-12-04T15:02:30.709000Z

This patch replaces every reference to the 'WIN32' macro with a reference to the '_WIN32' macro. Previously, both WIN32 and _WIN32 were used. _WIN32 is always defined by MSVC itself, unlike WIN32.

This change obviates the need for the Windows build configuration to define the WIN32 macro.

#12 Windows Build Fixes re. Atomics

2022-11-20T17:53:08.611000Z

Inapplicable as of FOX 1.7.81 which includes a similar change, but uses '_InterlockedExchangeAdd64' rather than '_InlineInterlockedAdd64'. [0] [1]

[0] https://learn.microsoft.com/en-us/cpp/intrinsics/interlockedexchangeadd-intrinsic-functions

[1] https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedexchangeadd64

Conditionally suppress mouse-movement propagation

2022-11-13T21:54:14.485000Z

(For FOX 1.7.80.)

In most GUI toolkits, if a modal window is shown, then if the user should mouse-over widgets of background windows (i.e. windows other than the modal one) then those widgets will not visually 'pop' as they usually would. (FXMenuTitle widgets are a good example.) Currently, FOX does not behave this way, and those widgets 'pop' as usual.
I had a go at bringing FOX into line with other toolkits in this regard.

Testing

I've tested my changes on Windows and on Kubuntu by:

Launch Adie
Hover mouse of FXMenuTitle widgets of the main Adie window, ensuring normal response (they should visually 'pop' when hovered over)
Bring up the About dialog (Help > About Adie...)
Hover the mouse over the FXMenuTitle widgets of the main Adie window

Expected outcome of Stage 4, prior to changes: the FXMenuTitle widgets 'pop' when hovered over.

Expected outcome of Stage 4, after applying changes: the FXMenuTitle widgets will not respond when hovered over.

Windows Build Fixes re. Atomics

2022-11-13T21:26:23.785000Z

I'm using Windows 10 on x86-64, with Visual Studio Community 2019 version 16.11.15, targeting 64-bit builds.

I had trouble building FOX on Windows:

fox-1.7.80\lib\FXAtomic.cpp(268,10): error C3861: '_InterlockedAdd64': identifier not found

The fix was to replace these calls with calls to '_InlineInterlockedAdd64', following Microsoft documentation.

('InterlockedAdd64' also seemed to work, but unlike 'InlineInterlockedAdd64' it doesn't appear to be documented. Curiously I wasn't able to get 'InterlockedAdd' to resolve even if I #include <intrin.h>, per further Microsoft documentation.)

I've not tested the atomics functionality after my change, I can only confirm that the build succeeds.
Also, I've not tested on any other Windows development environments, e.g. different version of Visual Studio.
I've also not tested 32-bit, I've not been able to get it to build (seemingly many different problems at play).

FIONREAD patch for OpenIndiana Hipster

2018-10-01T02:59:24.915000Z

--- fox-1.6.57/src/FXGUISignal.cpp.~1~  Tue Apr  3 23:42:42 2018
+++ fox-1.6.57/src/FXGUISignal.cpp  Sat Jul 14 23:02:52 2018
@@ -45,6 +45,10 @@
 #endif
 #include "FXGUISignal.h"

+#ifdef __sun__
+   #include <sys/filio.h>      /* For FIONREAD */
+#endif
+
 /*
   Notes:
   - On UNIX, pipe will be closed on exec of child process; we don't want

renaming enum FXFont::X11 to RawX11

2007-05-16T13:43:38Z

Renames X11 enum to RawX11, due to a macro conflict

workaround for Mach system header

2007-05-16T13:42:11Z

enum POLICY_FIFO conflicts with a Mac OS X macro

Universal Binary endianness

2007-05-16T07:38:18Z

The current fxver.h hardcodes the endianness to what the build system is using for the current target platform.

This doesn't work with Universal Binaries, that use the same header for two architectures (PowerPC and Intel).