Messages

16

Feature requests / Window improvement

« on: October 31, 2010, 10:08:25 am »

Thank you very much. I'll try that. Just thought of it, what are the technical limitations if you made a function that took a functor that would be executed when WM SIZING is emitted ?
In that case, the process wouldn't be blocked. Can this be a solution ?

17

Feature requests / Window improvement

« on: October 30, 2010, 08:39:07 pm »

Yes, except that you don't call DefWindowProc, but the callback installed by SFML (that you get back when you install your own callback). Otherwise SFML will not catch any event.

How can I know the Callback function installed by SFML ?

So you're saying that you do need to handle the copy event?

Yes, but not the timer. But there might be someone who will want to handle the timer event and not the copy event...


Forgot to ask, is there the same problem with linux when resizing the window ? If so, how can I deal with it ?

18

Feature requests / Window improvement

« on: October 30, 2010, 07:44:58 pm »

DefWindowProc is the default event callback, the one that you must call from your own event callback when you're not interested in the event, to let the OS do its job.
An event callback is attached to a window when creating its class (WNDCLASS), with the lpfnWndProc member. If you want to insert your own event callback after the window is created, use SetWindowLongPtr with the GWLP_WNDPROC flag; and don't forget to call the initial event callback in your own one (instead of DefWindowProc)

If I understand well, I need to add another function that will be called for each Event ? This function will then check if it is a WM_SIZING message (and call whatever function I want) and if not it calls the DefWindowProc ?
Isn't this system a bit heavy just to get one message ?

I'm waiting. I mean, for someone who really needs it of course Smile
I'll never add a feature that might be useful in the future.

I do if I don't want to check CTRL + C by myself ... There's a way around it by checking if both keys are pressed and then deal with it...but it so much simpler using the OS.

19

Feature requests / Window improvement

« on: October 30, 2010, 07:24:27 pm »

At low-level, you catch a window's events with a callback that the OS automatically calls when something happens. SFML has its own callback internally, then it translates the messages to sf::Event and store them until you call GetEvent.

I only found DefWindowProc and haven't completely understood it all (if I understand well it permits you to register a function that will process all Events and not a specific event).

It's easy for me, but then it's so complicated for users.

But what if some users ask for it ?! It won't even messy the public API !

Every window has an event callback attached to it, to which it can send its events. It's easy to setup (one call). SFML windows already have an event callback, which is attached by SFML to catch the windows events and translate them to sf::Event. But you can install your own callback between the window and the SFML callback, that's what SFML does when you pass an external window (a window that SFML didn't create): it still has its original event callback, plus the SFML one. If you're interested I can show you how to do it.

I'm quite interested thanks for spending so much time.

20

Feature requests / Window improvement

« on: October 30, 2010, 06:52:31 pm »

No, but it's probably a while loop that calls the window's event callback until the resize operation is finished.

Does this mean we can register a callback function ? If so, how ?

There are tons of messages, but most of them are irrelevant. Do you actually need these events, or are they just random examples?

These are random examples that could be used : Even in regular Textbox, there is a copy and paste function.
I don't really see why it shouldn't be implemented and in some cases it might be usefull :
-It's only one Event so it will not messy the API
-It is very easy to implement.
-It can even be usefull for a Textbox !

You don't need to run a separate event loop on your side. You can subclass the window, which means inserting your own event callback into the events chain.

Didn't really get that, but I guess that by searching, I'll find out...

21

Feature requests / Window improvement

« on: October 30, 2010, 06:19:48 pm »

Separate drawing and event handling in two separate threads.

What if I want to do something else when the window starts resizing ? Do you have a link that would explain how windows blocks the process ?

Let's suppose I wanted to pass to fullscreen as soon as the user starts resizing the screen, how could I achieve that ?

Ok. So my answer is no Smile
Unless you tell me why you need it, and maybe then it would be better to officially add the missing events to sf::Event, rather than providing raw access to system specific events.

What about WM_COPY Message could'nt that be delt with inside SFML, or even timer messages...
This kind of event permits the user to get Events that do not neccesarily have to do with the window to deal with them at the same time (it would be a waste to add another test with TranslateMessage and Dispatch message for nothing).

22

Feature requests / Window improvement

« on: October 30, 2010, 06:12:32 pm »

I don't see anything against it.

Perfect : We won't see the window being recreated when it is just the style that changed.

What do you mean?

I mean like this in SDL.

No, it's not possible. Threads are not an option if you talk about handling it internally. Only user code can work around this limitation.

Do you know how ? I searched and couldn't find anything.

23

Feature requests / Window improvement

« on: October 30, 2010, 04:43:07 pm »

Hi all, I would like to propose one more Function for sf::Window and a few more Event :

It would be nice to be able to change the style without recreating the window : to have something like :

void sf::Window::ChangeStyle(sf::Style);

Furthermore, it would also be appreciated to have something like system specific events.

Would it be possible to improve ResizeEvent and have a function EnableResizeRepeat(bool); ?

This function would enable Resize Event to be emitted even when the window is not already completely resized.
I've already talked about that on a other forum and it seemed there were technical difficulties but thanks to threads they might be avoidable :

Laurent told me that windows blocks the process when the window is sizing.

Would it be possible to have these features for SFML2 ?

24

General / Input field, data readed from file, using tables with paths

« on: October 25, 2010, 07:42:20 pm »

In C, you cannot do operator overloading (hope that's the term in english).
You should read a full C tutorial before doing that kind of thing :
There might be helper function in CSFML but if there isn't, you must allocate memory and then add your character. You basicly do the same thing as when using char* to manipulate characters.
Furthermore, I recommend you switch to c++ because c++ permits you to do this kind of thing without advanced knowledge. However, nothing stops you to do it in C, but you will need a bit more practice.

25

General / Input field, data readed from file, using tables with paths

« on: October 25, 2010, 11:02:26 am »

I guess you are using CSFML ?
In that case, this lign seems very strange :

test+= Wydarzenie.Text.Unicode;

What are you expecting it to do ?

26

Graphics / sf::String and size errors

« on: October 16, 2010, 10:07:43 am »

Thanks, never had to use sf::Glyth but I'll try it...

27

Graphics / sf::String and size errors

« on: October 15, 2010, 09:34:21 pm »

Not yet, sorry. I move it up in my todo list

thanks...

28

Graphics / sf::String and size errors

« on: October 15, 2010, 07:47:12 pm »

I don't really understand the idea of font metric's. Could you give me a clue of how to calculate the cursor's position ?

In fact it should be ok with GetSize(), I'll do some tests to see what's wrong.

Hi, I wanted to know if you had found what was wrong with GetSize().

29

General discussions / Retro compatibility

« on: October 07, 2010, 08:41:42 pm »

thanks, as soon as I make my project work with 1.6, I'll try to switch it to 2.0

Yes, there will be masks based on GL clip planes implemented in SFML 2.

"will" means it is not yet implemented (in which case I should wait a bit...)?

30

General discussions / Retro compatibility

« on: October 06, 2010, 08:41:34 pm »

The drawables rendering stuff may not be stable (I'm talking about public interface, not robustness). I still hope to find a better design for this area before the final release. So if your code uses a lot of custom drawables, or makes OpenGL commands interact with SFML rendering, think twice before switching to SFML 2.

For the moment, I only use GLClipPlane to ensure each object of my GUI stays in the rectangle it has been assugned in,  but of course there may be other calls to OPENGL. Is glclipplane still working with 2.0 ? Is there another way (that keeps performances) ?
I haven't found any feature in 2.0 that I really need yet. Sf::RenderImlage is interesting but i've made my own specific class which may be quicker.

Work is not really a problem as long as it doesn't ask to rethink the whole architecture.