Windows/Awesomium custom UI by hiding win frame

[Garrador]

Hi there. I recently posted a question over at stackoverflow, but noone has given a clue just yet. I was hoping maybe some of you here are familiar with either Awesomium or the Windows API.

(Here is the question: http://stackoverflow.com/questions/1946 ... -awesomium )
I posted all the source code there.

Anyways, some progress since I posted it: The CustomCaptionProc method is called, but the hittesting is never fired as it does not send any messages when the mouse is over the borders.

What I need specifically is to be able to resize and move the window, as well as using the standard (win 7/8) "snap" to the screen edges.

This is the one thing that is missing before I feel comfortable moving on with the app.
It does seem like the awesomium surface is somehow interrupting the hittest on the frame behind, or that it is not considered NCA.

Regards, Øyvind

[zombie@computer]

First of all i dont know awesonium; it sounds like 'just another html control' of which there are tons, but perhaps i mistunderstand.

Second of all i'm not very familiar with the windows api either (other than through C#; obviously because a lot of windows API stuff in c++ costs so much effort to do even the most simple stuff).

What i do know, from c# that is, is that when you remove the windows frame, you also remove functionality that is part of the windows frame; ie dragging the screen, resizing etc. You'll have to implement these things yourself; its way easier and stable than trying to find and re-link the windows functionality.

If that is not the problem i cant help you other than advising you to dump c++ if you just stick to windows and start using c#.

[Garrador]

Yes, in C# that is the case. But here, the client area is simply "extended" beyond the borders. If I comment out the drawing part of the awesomium surface, you can see the whole window with the frame and caption. The HitTesting is to go "below" the awesomium surface to focus input on the caption and borders. This is whats NOT happening though.

I need C++ here for portability, as C# doesent provide much of that, unfortunatly, as I like programming in C#

Anyway, thank you for the input. If I cannot figure this out soon, I'll first get pissed, then I'll find another way to do it, heh. The snapping-to-edge feature in Win7 and up is harder to implement though, as it can work together with other windows. I know its possible, but there is some detail I'm missing.

Thanks

[SM Sith Lord]

I am familiar with Awesomium API and a little with the Windows API, but I have never used Awesomium's window mode before so I don't know how it handles its own window.

From the sound of it, it is only the Windows API that is causing your issue. I'm not sure if expanding your window's client area to overlap its border is a good way to go. It seems like this would put the client area ontop of the boarder and steal your click events, as you described. I'd try to find a way to just turn the window border invisible, or adjust its size to be very small, or both. Never looked for this kind of stuff in the Windows API before though, good luck.

My understanding is that you want to keep the default window resize features while having no visible window border.

[Garrador]

Thank you for your answer! The first to answer with anything from here to CodeGuru/StackOverflow/Awesomium Helpdesk etc. Hah.

I'm however not expanding the client area "over" the borders themselves. I'm rather expanding the area of which is considered to be a renderable client area. The whole windows frame is all fine and intact underneath the drawn UI (tested by setting the transparacy to 0 on WebView).

What I'm thinking is that the webkit rendering engine ultimately handles or swallows every input available as long as it's in Windowed mode. I have built a simple and hacky workaround by using javascript onmouse* events with callbacks back to the native app for messages. Not my preferred solution however, as this effectively eliminates the basic functionality of resizing and snapping in the windows desktop.

My understanding is that you want to keep the default window resize features while having no visible window border.

Correct. I'm thinking of hiding the frame in the exact same way I'm doing now, but using another UI package (like QT or something), and see if the same happends then.

[SM Sith Lord]

Maybe you could make the entire webview not capture any mouse messages at all, but create an invisible, slightly smaller surface in front of the webview that passes input to it. If that is possible, it should allow default operations on your window border.

[Garrador]

Hmmmh. I have not found a working solution yet. Atm I have not been able to do what you suggested either..
For now I'll put this project on ice, and find another cross-platform UI library (QT or GTK). Although I prefer using HTML/CSS for the style itself. I've heard QT designing is much like CSS though.