Messages

1

General / Re: Using SFML with CLion on Windows with MSVC2022 x64 toolchain CMake and Ninja

« on: May 02, 2022, 08:21:43 pm »

I use MSVC2019 + CLion 2022.1 (using CMake 3.21) + SFML 2.5.1 and here's the CMake project template I use for it:

# use static libs
set( SFML_STATIC_LIBRARIES TRUE )

#directory where the cmake files for SFML are. You will want to change this to wherever your SFML installation is
set( SFML_DIR "D:/projects/SFML-2.5.1/lib/cmake/SFML" )
find_package(SFML 2.5 COMPONENTS graphics window main network audio REQUIRED)

target_link_libraries( ${PROJECT_NAME}
    PRIVATE

    sfml-graphics
    sfml-window
    sfml-main
    sfml-network
    sfml-audio
    )
 

Unless you're altering the source, have some system-specific optimizations you require, or want to perform testing on the (unstable) master branch, I wouldn't bother building from source. There are binaries available for Windows here: https://www.sfml-dev.org/download/sfml/2.5.1. In your case, both the 2015 and 2017 versions will work.

2

Window / Re: Using SFML as a child window without access to Event Loop

« on: October 20, 2021, 07:43:03 am »

Thanks for the contact.

Does the reverse not work, of calling .create with the HWND after you've created the child window yourself?

That is what I'm currently doing. It works if I create the native child window myself, call create( childHWND ), and then process the SFML loop via the SetTimer callback. Another way is to also have SFML create a new window using sf::Style::None, call SetWindowLongPtr to update the dwstyle, call SetPosition to enact the update, and then call SetParent to attach it.

The problem with the sf::Style::None option is that SFML sets dwstyle to WS_POPUP, which cannot be used with WS_CHILD but it does get around other dwstyle issues on initial SFML window creation.

Regardless of which route you take, you're left making quite a few OS-specific calls. There's probably very little demand to add a cross-platform feature for something like createAsChildTo( parentSystemHandle ) but that would be ideal for folks who are looking for plugin solutions.

3

Window / Re: Using SFML as a child window without access to Event Loop

« on: September 17, 2021, 05:51:28 am »

For those interested, I've managed to get SFML working pretty well whenever there's not direct access to an event loop AND whenever you have to create a native Win32 child window first that SFML then consumes. Some gotchas:

1. SFML takes over whatever data you've stored in SetWindowsLongPtr GWLP_USERDATA with its own sf::priv::WindowImplWin32, which you don't have public access to.

2. SFML doesn't trigger any events on WM_TIMER, so you'll need to SetTimer() with your own callback in order to create your own event loop. You'll need to map the child HWND used with SetTimer to your class due to issue 1.

3. Don't create the win32 child window using CW_USEDEFAULT for width and height because it'll return 0, which makes SFML scale things oddly. Know your starting window size in advance, if possible, by getting it from another API or using GetWindowRect. Somebody with more SFML experience may know how to scale properly once your original size is set to zero and then you call sf::Window::setSize( { >0, >0 } ).

4. Don't mistakenly call sf::Window::create() AFTER other adjustments, such as setSize, setActive because you haven't actually created anything yet and you'll bang your head

5. You must call SetFocus( getSystemHandle() ) directly on timer callback or else keyboard events won't be available. The sf::priv::WindowImplWin32::requestFocus() calls SetForegroundWindow() when on the same process thread or flashes a window notification but there's nothing in the API that calls SetFocus on your behalf

There was a lot of trial and error and I still had to perform quite a bit of native API wrapping. Originally, I was hoping to be able to have SFML create a child window automatically for me by giving it a parent window handle. Maybe I'm the only dope who wants this use case though.

4

Window / Using SFML as a child window without access to Event Loop

« on: September 10, 2021, 11:49:09 pm »

First, let me just say that I really enjoy SFML and really hope that there are no issues with my design intent.

The Scenario:

The VST3 framework controls the parent window and the event loop so you cannot use pollEvent.

So I've been writing test code that allows me to create a native Win32 child window and then wrap the HWND in a sf::WindowHandle and then pass that to sf::RenderWindow, which works great.

For events, I've been forwarding messages from my Win32 wndProc callback to my SFML wrapper that the sf::RenderWindow can process draw on WM_PAINT, close on WM_CLOSE/WM_QUIT and then perform a few mouse and keyboard events.

Everything seems to work fine so far.

The Problem:

The conversion from the WinApi events to sf::Event is handled privately via WindowImplWin32. So I have two questions:

1. Is there actually a public-facing interface from SFML that enables native event conversion to sf::Event?
2. Are there known any issues or undefined behavior that can occur if I continue down this path?

Thanks!