Previously, the top-level modal dismiss broadcaster would attempt to
dismiss all modals when the native file chooser was brought to the front
or clicked. This would end up calling Component::inputAttemptWhenModal,
which would bring the FileChooser's Component to the front, interrupting
the mouse click.
The fix is to avoid bringing the plugin window to the front when the
FileChooser is in a modal state. As the chooser is a native window, the
system should take care of enforcing the expected modal behaviour.
It's not clear why this issue only affects Cantabile. It seems that in
Cantabile, events from the native FileChooser get sent to the plugin
editor's parent HWND, whereas this doesn't happen in other hosts.
Perhaps Cantabile is hooking/intercepting window messages in some way.
- Created a new detail namespace
- Moved shared module implementation details into the detail namespace
- Split dependencies so source files only rely on details in the detail namespace
- Removed all code from the juce_gui_basics.cpp file
Fixes a bug on Windows when opening a FileChooser with the following
arguments.
FileChooser ("",
"C:\path\to\file", // filename 'file' doesn't contain '.'
"", // all extensions are allowed
true);
The expected behaviour is that the initially-displayed filename is
"file".
The actual behaviour was that the initially-displayed filename was
"file.file".
The previous method for finding the dialog's owner was ineffective, and
it was still possible for other windows to obscure the file picker in
many cases. Using GetActiveWindow seems to produce the expected
behaviour.
With this patch applied, the DemoRunner should build under MinGW, and be
(nearly) feature-complete compared to the MSVC build.
Specifically, when building with MinGW:
- Adds support for accessibility
- Fixes build issues in the juce_video module
- Fixes a link issue in the VST3 wrapper when VST3_CAN_REPLACE_VST2 is
defined
- Adds support for the new-style native FileChooser
- Tidies up some other low-severity warnings
Known issues:
- Direct2D rendering is still not supported when building with MinGW due
to ABI compatibilities.
IFileDialog::Show and CoUninitialize both seem to require the main
message loop to be active and running when they are called. If we block
the message thread while calling these functions, we may cause a
deadlock.
The destructor of the Win32NativeFileChooser was blocking the message
thread until the background thread exited, but the background thread was
unable to make progress while the message thread was blocked.
To work around this issue, we now pump the message thread in the
destructor of the Win32NativeFileChooser. If a dialog is currently
active, this should allow it to exit gracefully.
Note that we cannot use MessageManager::runDispatchLoopUntil here:
- MessageManager::runDispatchLoopUntil will not process any messages if
the quit message has been received, which could lead to deadlocks if the
FileChooser is destroyed after the quit message has been posted.
- This function isn't defined when JUCE_MODAL_LOOPS_PERMITTED is disabled.
It seems like shared_from_this may not be enabled when a unique_ptr is
assigned to a shared_ptr (although it *should* be enabled when
constructing a new shared_ptr from a unique_ptr). Functions that return
objects that may need to use shared_from_this now return shared_ptr,
just to be safe.
Additionally, in some cases, shared_from_this was being called from
Thread::run after the last reference to the shared object had been
released. We now call shared_from_this during 'open', which will always
run on the message thread while at least once reference to the shared
object is alive.
The Win32NativeFileChooser was taking ownership of itself
in its `Thread::run` implementation. This meant that sometimes
the destructor of the file chooser thread would execute directly
in `Thread::run`.
Now, we explicitly transfer ownership into a function object which
will run asynchronously on the main thread. This way, the file chooser
thread will be stopped on the main thread.
Tom Poole
reuk
Anthony Nicholls
Oli
ed
jules