AAX resizing Bug and fix

[chkn]

in the AAX wrapper GetViewContainer()->SetViewSize(newSize) can FAIL

this can happen when the plugin is too big (like described in the comments) but also if the offscreen bounds of the plugin are too big.

The result is that the internal size, and the window size are different, which may hide important controls in the plugin (including resize-symbol)

This is a fix for the AAX Wrapper
It remembers the last successful resizing of the plugin, and if it wasn’t successful, it just applies the old size to the internal plugin again.
A listener-loop (because of the component lister) should not happen, because it checks if the current size is equal to the new size)

			Point<int> lastCorrectSize;
			void childBoundsChanged(Component*) override
			{
				if (pluginEditor != nullptr)
				{
					auto w = pluginEditor->getWidth();
					auto h = pluginEditor->getHeight();

					if (lastCorrectSize.isOrigin() || lastCorrectSize.getX() != w || lastCorrectSize.getY() != h)
					{

						AAX_Point newSize((float)h, (float)w);
						if (owner.GetViewContainer()->SetViewSize(newSize) != AAX_SUCCESS)
						{
							// Because setViewSize has failed, we have set the internal plugin-size to the same size
							// this is tricky because the constrainer may not allow smaller bounds, but if we don't do it the internal size 
							// is bigger than UI element, and may hide important controls;
							
							auto bounds=pluginEditor->getBounds();
							bounds.setWidth(lastCorrectSize.getX());
							bounds.setHeight(lastCorrectSize.getY());
							pluginEditor->setBoundsConstrained(bounds);
							
						}
						else
						{
							lastCorrectSize.setXY(w, h);
							setSize(w, h);
						};
					};

				}
			}

[chkn]

bump

[fr810]

This is now fixed on develop with commit b4da453.

[chkn]

thanks, i cannot compile because

jucedev\modules\juce_audio_plugin_client\aax\juce_aax_wrapper.cpp(606): error C2872: 'Rectangle': ambiguous symbol

– > have to use juce::Rectangle

[fr810]

Thanks I’ve pushed a fix for this to develop (it will appear shortly). Just to avoid this in the future - with which compiler are you seeing this. Our CI system did not flag this and we build with VS2015 and VS2017, Xcode.

[chkn]

VS2017

[fr810]

Hmmm that’s odd. We build with VS2017 as well. Do you include any extra headers? Which AAX SDK version are you using?

[chkn]

#define AAX_SDK_VERSION ( 0x0203 )

No extra headers

In projucer windows target platform is 8.1 (??? i never had set this, i will try remove it, to use the default value)

[chkn]

with default sdk same problem

[chkn]

rectangle from wingdi.h

include hierarchy

Note: including file:   jucedev\modules\juce_audio_plugin_client\aax\../utility/juce_IncludeSystemHeaders.h
Note: including file:    C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\windows.h
Note: including file:     C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\wingdi.h

[railjonrogut]

See if this helps:

'Rectangle' : ambiguous symbol

I’m having exactly this problem while trying to arrange some existing sources in “juce module” fashion. One of these .cpp files needs windows.h so I put an #include for it into the main “juce_module.cpp” file. This causes all the other .cpp files that use Rectangles to complain like shown above. What is the preferred way to cope with this?

define NOGDI before any Windows headers:

#if defined(_MSC_VER)

#define NOGDI
#include <windows.h>
#include <WinBase.h>
#include

#endif
You can also define WIN32_LEAN_AND_MEAN after defining NOGDI (if that’ll work for you).

Rail

[fr810]

Thank you. I’ve already just put juce:: namespace in front of the single use of Rectangle. But good to know.

[APRiedweg]

Hi all,

Digging into juce_audio_plugin_client_AAX.cpp (JUCE 8.0.14), I can see the childBoundsChanged/resizeHostWindow mechanism already does what the 2018 thread proposed (checking SetViewSize’s return value):

bool resizeHostWindow()
{
if (pluginEditor != nullptr)
{
auto newSize = convertToHostBounds ({ (float) pluginEditor->getHeight(),
(float) pluginEditor->getWidth() });
return owner.GetViewContainer()->SetViewSize (newSize) == AAX_SUCCESS;
}
return false;
}

void childBoundsChanged (Component*) override
{
if (resizeHostWindow())
{
setSize (pluginEditor->getWidth(), pluginEditor->getHeight());
lastValidSize = getBounds();
}
else
{
pluginEditor->setBoundsConstrained (pluginEditor->getBounds().withSize (lastValidSize.getWidth(),
lastValidSize.getHeight()));
}
}

Setup: JUCE 8.0.14, Pro Tools Developer (latest). Plugin works fine in VST3/AU — issue is AAX-only.

Symptom: On first insert on a new track, the editor opens at a much smaller size than the frame Pro Tools reserves (grey gap around it). Dragging the corner manually fixes it instantly.

My read of the code: lastValidSize defaults to an empty Rectangle. If SetViewSize fails on the very first childBoundsChanged call (likely because the host’s ViewContainer isn’t fully ready yet when the editor first reports its size), the editor gets clamped down to lastValidSize (0x0, constrained to the resize limits minimum) instead of the size I actually requested in the constructor. This would explain both the small initial size AND why repeatedly retrying setSize() from a timer didn’t help — each retry re-triggers childBoundsChanged, and if the host still isn’t ready, it gets clamped back down again.

Questions:

1. Is this understanding correct?
2. Is there a known timing/readiness signal I should wait for before requesting my initial size, to avoid landing in the SetViewSize-fails branch?
3. Would initializing lastValidSize to the intended starting size (rather than leaving it default-constructed) be a reasonable local patch, or is there a cleaner supported way to influence the initial AAX view size?

Thanks!