Messages

1

Window / Re: Native Menus

« on: March 03, 2014, 12:22:13 pm »

SFML is a libray for multimedia/game development. For these cases it is unusual to use the native GUI API delivered by the OS. Since almost every game uses its own GUI -- often for aesthetical purposes -- it is outside the scope of SFML to use native APIs.

I don't want SFML to be cluttered with those additions that would be necessary to use native GUIs. I wouldn't use it either.

And in those cases where you need such an integration (e.g. maps editors or the like), the current state of integration between Qt and SFML is more than sufficient.

Well, enabling it (for Win32 anyways) is only 10 lines of code, so it's hardly clutter. Also, hardcoded menu drawing is already in SVN for OSX, since OSX requires a menubar. That menubar is just not modifiable and the entries are greyed.

If SFML will not support native guis, it should at least not block it.

2

Window / Re: Native Menus

« on: March 03, 2014, 03:34:09 am »

If menuing isn't to be added to SFML (which I can understand, though I see menus as part of the window creation), the support for user handling of events not used by SFML is a must I think. As-is, SFML blocking things like WM_COMMAND from the user actually makes the API lesssimple by requiring the user to re-implement gui from the ground up (instead of using native api), or forcing them to abandon SFML as their core framework and just use it as another lib in addition to qt/wxwidgets/etc.

In any case, for now I will use my 'fork' with the additional menuaction event type.

3

Window / Re: Native Menus

« on: February 28, 2014, 01:42:02 pm »

Although you've said in the past that you don't consider SFML to be a gui api, would you be open to enabling basic cross-platform menu handling? Basic OSX menus were added in a recent commit, so the next logical step would be exposing it in the API.

I do agree that creating "in-game" menus like SFGUI etc do is far beyond the scope of SFML, but native gui would fit in well I think. Creating windows with controls etc may also beyond the scope in that it requires defining layouts, but basic menuing would be quite easy to do.

I've already thrown together such an API myself and modified SFML to do the events through its handler, but it would be nice if it was in mainstream (and cross-platform).

4

Window / Re: Native Menus

« on: February 28, 2014, 06:08:23 am »

As a simple test I made a modification to WindowImplWin32.cpp that gets menus working 90% 100%:

in WindowImplWin32::processEvent() at the end of the big switch:

case WM_COMMAND :
        if (HIWORD(wParam)!=0) break; // Only handle menu sources
        Event event;
        event.type = Event::MenuitemSelected;
        event.menuAction.identifier = LOWORD(wParam);
        pushEvent(event);
        break;

Along with creating the obvious structures in event.hpp. Now I can use SFML's event handler to handle menu events. I've only tried handling the menubar though, no dialog boxes and whatever else. That is enough for my current project.

The reason I say 90% and not 100% is that my app now hangs on exit. I'm guessing it's something related to it somehow skipping SFML's handling of quit messages, but I don't understand how. (My window closes and the console stays behind, followed by Windows saying the app has hung)

-edit-
Actually, it turned out to be a problem with the SVN (it hangs on exit even with a virgin copy of the source, compiled with MSVC2010).
I applied my same modifications to the 2.1 release source and it works 100% fine now.

5

Window / Re: Native Menus

« on: February 28, 2014, 02:37:36 am »

Thank you for the reply.
I am trying to keep my app as cross-platform as possible while still providing a native look (Win32 & OSX, with #ifdef to choose the menu coding), so I think going full-blown Win32 api might be too messy.

Are there any plans to allow the user to handle events that SFML itself doesn't (such as WM_COMMAND)? For example, by adding another EventType enum that just passes through the event number (ex: 0x0111 for WM_COMMAND) and the wparam/lparam when SFML doesn't know it. It would probably be useful for many situations aside from just menuing.

When I was searching for answers to my problem I noticed that you have said on several occasions that SFML is not a GUI API, but that doesn't seem to contradict exposing some functionality so the user can do it themselves.

6

Window / Native Menus

« on: February 27, 2014, 11:51:08 am »

I am trying to implement native Win32 menus in my app.
I am able to display and interact with the menus:

auto hMenu = CreateMenu();
auto hSubMenu = CreatePopupMenu();
#define ID_FILE_EXIT 9001
AppendMenu(hSubMenu, MF_STRING, ID_FILE_EXIT, "E&xit");
AppendMenu(hMenu, MF_STRING | MF_POPUP, (UINT)hSubMenu, "&File");
SetMenu(window.getSystemHandle(), hMenu);

and also able to directly receive window messages:

MSG message;
while(PeekMessage(&message, NULL, WM_COMMAND, WM_COMMAND, PM_REMOVE)) {
    //do_stuff();
}

but I never receive any WM_COMMAND messages that the menus should be sending out. (if I change both the WM_COMMAND in the PeekMessage call to 0, I get mouse etc events, but asking for only WM_COMMAND gives me nothing)

I am not very experienced with the Win32 api, so I am not sure if I am using the wrong method for WM_COMMAND messages, or if somehow SFML is eating the message before I can see it. I am doing the PeekMessage stuff before my SFML event handler, if that matters.