//==============================================================================
/** This is the top-level window that we’ll pop up. Inside it, we’ll create and
show a HelloWorldContentComponent component.
*/
class HelloWorldWindow : public DocumentWindow
{
public:
//==============================================================================
HelloWorldWindow()
: DocumentWindow (T(“Hello World”),
Colours::lightgrey,
DocumentWindow::allButtons,
true)
{
setContentComponent (new HelloWorldContentComponent());
setVisible (true);
centreWithSize (400, 200);
//Win32ComponentPeer* peer = reinterpret_cast <Win32ComponentPeer*> (m_parentComponent->getPeer());
Win32ComponentPeer* peer = NULL;
peer = Win32ComponentPeer::getOwnerOfWindow ((HWND)this->getPeer()->getNativeHandle());
}
~HelloWorldWindow()
{
// (the content component will be deleted automatically, so no need to do it here)
}
//==============================================================================
void closeButtonPressed()
{
// When the user presses the close button, we'll tell the app to quit. This
// window will be deleted by the app object as it closes down.
JUCEApplication::quit();
}
It’s an in-line class, so there’s no way of using it outside of juce_win32_Windowing.cpp. And it’s done that way deliberately to stop people messing with it!
What is it that you’re trying to do? There’s probably a better way of going about it.
No it is not to mess with code. It is to be able to set a windows proc hook very cool on windows. the peerWindowProc function should not be private, it should also be a pure virtual.
Windows is a very “message proc” oriented OS and beeing able to reinterpret the message proc before forwarding message to the juce core is quite an interesting approach even in some case the hook will be specific only to WIN32. #ifdef will do the trick.
Yeeesh… no way is a win32 callback going to become virtual or even public in any library of mine! That stuff should be buried as deep as possible!
If you just want to add a hook, you can get the HWND with the getNativeHandle() method. But then why do you want to add a hook? What can’t it already do that you need to do?
If i just use the handle unfortunately nothing is painted by using the defwindow proc. Also i was using the MessageManagerLock… The toplevel window was frozen unless i was calling peerWindowProc. There is scenario where it is important. Lets say for example if you need to do interprocess communication with RegisterMessage… How can juce handle custom message ??
BTW i don’t want to discuss that in the forum. As far as windows proc i agree that it must be hidden because of cross platform issue and the all purpose of Juce but again i manage to change the peerWindowProc to a public virtual method and it Works like a charm. Some app will need maybe 10% of the time to reinject.
Most of them won’t but this is why there is framework. To bring features to Developers knowing that by doing that i will break cross platform, overall the code will still be 90% cross platform. The more the better.
BTW your framework is a kick asss framerwork jules !
InterprocessConnection is a great alternative thanks but still
how to use SetWindowsHookEx on Windows.
I think having the winproc public only open possibility in some cases to take the best advantage of one OS versus an other.
adding up to 5% of #ifdef WIN32 is not a big deal to me. You just have to use some naming convention which explicitly tell user that this is an OS dependent call.
“#ifdef WIN32” is exactly what I set out to avoid in designing the library. If there’s functionality that’s missing, it gets added as a set of meaningful, platform-independent classes, and platform-specifics kept hidden. Opening up low level code is missing the point completely.
But like I said earlier, you don’t even need a dreadful hack to add a hook - you can do it without changing a single line of library code just by getting the window handle. I add a window hook that way in the VST wrapper, I think.
<< “#ifdef WIN32” is exactly what I set out to avoid in designing the library. If there’s functionality that’s missing, it gets added as a set of meaningful, platform-independent classes, and platform-specifics kept hidden. Opening up low level code is missing the point completely. >>
this is what i call a STRONG POINT !
and a low level handle is enough for everyone (much like 640kb was in 80’s)…
What about ActiveXControlComponent
does this class available in Juce can be use on the MAC and on Linux ???
What are your ideas to provide a browser control in juce (cross platform)
Are you planning to use mozilla as a static library ?
i simply not use that class at all… i have no activex needs right now, but dirty other class interface with methods like HWND getMyWindowSpecificHooksThatICantLiveWithout is not the point !
So then on Windows i have to use #ifdef WIN32 and comeup with two class to integrate a web control inside a Juce App. One for Windows which is the Internet Explorer Active X and one for the mac using cocoa.
Interesting debat anyway. 100% cross platform is a long path.
Keep the hard work, i am sure a guy will come up with a juce Mozilla component someday…
i’m not a big fan of apps that display webpages with external browser controls. yeah 100% cross platform is utopia: just trying to be constantly at 99% (at least for what is possible inside my high level applications).
if i need something like this, i will stroke a good quality svg page in inkscape and let it pass into the juce rendering path
