Well, if the code is too complex to debug, the usual solution is
to try simpler code and see if it works.
On Sunday, 7 April 2019 at 22:18:56 UTC, Johan Engelen wrote:
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote:
This generally works OK when tied to a Console but when link
options are changed to be SUBSYSTEM:WINDOWS and
ENTRY:mainCRTStartup it rarely does.
Manually setting
On Sunday, 7 April 2019 at 14:49:20 UTC, Archie Allison wrote:
The codebase is a reasonable size so too big (and proprietary)
to share.
You can reduce it to a minimal example that doesn't work. Static
variables are thread local by default in D unless they are marked
as shared or __gshared.
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote:
This generally works OK when tied to a Console but when link
options are changed to be SUBSYSTEM:WINDOWS and
ENTRY:mainCRTStartup it rarely does.
Manually setting the entry point sounds problematic if no other
precautions are
On Sunday, 7 April 2019 at 17:52:40 UTC, Mike Wey wrote:
How are you using the GUI, GTK is not thread safe, all gui
function calls should be made from the GUI thread.
Last time i checked threadsEnter and threadsLeave didn't work
properly on windows.
All GUI updates are sent from a
On 07-04-2019 16:49, Archie Allison wrote:
The codebase is a reasonable size so too big (and proprietary) to share.
It's always run with a GUI (GTKD), it's just the difference in linking
so launching (a)GUI + attached console for stdout.writeln vs. (b)just
the GUI window. There's nothing I'd
On Sunday, 7 April 2019 at 14:35:24 UTC, Doc Andrew wrote:
When you say it "rarely works" when run as a GUI app (vs
console), it makes me think that there's probably a race
condition going on, and the extra context switching that takes
place in GUI mode makes it more likely. I haven't tried
On Sunday, 7 April 2019 at 14:08:07 UTC, Archie Allison wrote:
I have written an industrial control program which uses serial
ports to communicate with hardware but am having problems,
perhaps with shared memory, on Windows.
The SerialPort class calls C object-file functions. Transmits
are
I have written an industrial control program which uses serial
ports to communicate with hardware but am having problems,
perhaps with shared memory, on Windows.
The SerialPort class calls C object-file functions. Transmits are
on one thread and receives on another (all within a class derived
