Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 4.9.8

This thread is locked; no one can reply to it. rss feed Print
Allegro 4.9.8
Don Freeman
Member #5,110
October 2004
avatar

I'm still waiting for the hidden..."Welcome to Allegro..." ;D

Is there a way to get the HWND for the current app using the current API...as in, not having to call FindWindow(className,windowName); ? I was thinking of adding some special Windows code like in the old API, any suggestions as to how I should go about that? Probably just look at the old API and see how it exposes the Windows API on a Windows system. I know some people didn't want special OS calls to be part of the new API, but sometimes it's needed.

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Evert
Member #794
November 2000
avatar

Quote:

I'm still waiting for the hidden..."Welcome to Allegro..."

I've been meaning to extract that sample and put it in the example data directory. Good that you remind me.

Quote:

Is there a way to get the HWND for the current app using the current API...as in, not having to call FindWindow(className,windowName); ? I was thinking of adding some special Windows code like in the old API, any suggestions as to how I should go about that? Probably just look at the old API and see how it exposes the Windows API on a Windows system.

I don't know enough about the Windows port to say one way or the other whether this is possible or not, although I suppose it must be (come to think of it, look at the file picker addon in SVN, I think it has code for doing that). What is it that you want to do exactly? There may be a way to do what you want to do without having to use Windows-specific functions, or maybe it is something for which we should provide a platform neutral interface.

Quote:

I know some people didn't want special OS calls to be part of the new API, but sometimes it's needed.

As with breaking the API between different releases, I'm in the "no unless" camp on this. If at all possible, a platform-neutral wrapper is the way to go for me. ;)

Todd Cope
Member #998
November 2000
avatar

I am using GetForegroundWindow() for now. It returns the HWND for the window which currently has input focus.

Thomas Fjellstrom
Member #476
June 2000
avatar

I'm with Evert. If what you actually want can be done in a platform neutral way we should do that before extending the api for OS specific stuff like this.

Much like theres a File Dialog addon now.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Don Freeman
Member #5,110
October 2004
avatar

Mainly I ask, because I was looking to add the clipboard functions (Windows for now, others could provide a Linux/Mac version)...but I need to do some OS specific stuff. I do not plan to expose any Windows specific code ideally, but I need to gain that access in my functions.

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Trent Gamblin
Member #261
April 2000
avatar

An HWND and a Window or Display or whatever X11 uses are pretty different. There is a way to get the HWND of a display if you're using direct3d, but it would be better if it was, if not cross platform, cross driver (meaning available with opengl in windows too).

Evert
Member #794
November 2000
avatar

Quote:

I was looking to add the clipboard functions (Windows for now, others could provide a Linux/Mac version)...but I need to do some OS specific stuff.

Sure, ok. Definitely have a look at the file selector addon, it needs to do something similar on Windows, I think.

Quote:

An HWND and a Window or Display or whatever X11 uses are pretty different.

So what?
You have some data structure that represents a window and that you pass around but never actually need to do anything with yourself, right? The only thing you care about is that the functions you want to pass it to know what to do with it.
Anyway, not to get into that discussion: if you need to write platform specific code (eg, in an addon), you need to write platform specific code. If we can wrap it in a platform neutral package, so much the better.

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

You have some data structure that represents a window and that you pass around but never actually need to do anything with yourself, right? The only thing you care about is that the functions you want to pass it to know what to do with it.

The ALLEGRO_DISPLAY essentially already is that data structure.

HWND *al_get_display_hwnd(ALLEGRO_DISPLAY *d);

Something like that for each platform is all that is needed. (Same thing A4 does.)

ImLeftFooted
Member #3,935
October 2003
avatar

This inspired the military camp comment:

Trent said:

.. drawn by Micah Crow (who is awol)

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

The ALLEGRO_DISPLAY essentially already is that data structure.

If he was saying what I think he was saying, he was thinking something more like:

void *al_get_display_oshandle(ALLEGRO_DISPLAY *);

One function covers all platforms, you just have to cast.

But what I was thinking was more along the lines that it shouldn't be a public function. If such a funtion is needed, look at what it is needed for first, and try to support THAT in a cross platform manner.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Evert
Member #794
November 2000
avatar

Quote:

One function covers all platforms, you just have to cast.

I'd make it return an ALLEGRO_OS_DISPLAY_HANDLE or something like that, but yes, that's the idea.

Quote:

But what I was thinking was more along the lines that it shouldn't be a public function. If such a funtion is needed, look at what it is needed for first, and try to support THAT in a cross platform manner.

Oh, absolutely.
I was thinking along the lines of a cross-platform wrapper that you can pass the cross-platform OS handle to, but I realised after posting about it that there's no need for something like that: Allegro internally knows what the OS handle on the current display is, so there would never be a good reason to specify it manually in that case.

Don Freeman
Member #5,110
October 2004
avatar

Quote:

Quote: One function covers all platforms, you just have to cast.
I'd make it return an ALLEGRO_OS_DISPLAY_HANDLE or something like that, but yes, that's the idea.

At first, I was thinking of having it part of the system driver. Then there could be an added function to call, such as al_get_display_handle( ALLEGRO_SYSTEM_DRIVER *driver ). Maybe that is not the correct way to go, but that was my main idea.

Quote:

But what I was thinking was more along the lines that it shouldn't be a public function. If such a funtion is needed, look at what it is needed for first, and try to support THAT in a cross platform manner.

Yeah...that was my thinking. I'm not sure how Linux or Mac handles clipboard data, but my goal was to expose something like this to the end user:

ALLEGRO_CLIPBOARD_DATA * al_get_clipboard_data( ALLEGRO_CLIPBOARD_DATA_TYPE
                                                type );
bool al_set_clipboard_data( ALLEGRO_CLIPBOARD_DATA *data,
                            ALLEGRO_CLIPBOARD_DATA_TYPE type );

Obviously, I would plan this out better, but that is the jest of my idea. All of the cross platform stuff would ideally be handled internally by the library.

Also, I was thinking that maybe we could have OS specific stuff exposed by including the OS specific headers, like the old API. If you need/want Windows specific stuff for some obscure reason, then just include <allegro5/winalleg.h> or such. I don't really want to limit the functionality of the library just for the sake of argument...especially if that functionality is indeed there in the lib, just not exposed to the user (as in the case of the HWND). In the end, we have to make the distinction that the end user should 'do the right thing'.

Edit:
On the note of a clipboard addon, what would you like to see in it? I was thinking of text, graphics, sound, and user defined types. There are a shit ton of different types in Windows, but those are the most basic. Any suggestions/ideas?::)

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Matthew Leverton
Supreme Loser
January 1999
avatar

Now I'm just confused. What good is ALLEGRO_OS_DISPLAY_HANDLE? What functions would receive it? It never would be an Allegro function. It would always be a platform dependent function.

What are you suggesting?

#ifdef WINDOWS
#define ALLEGRO_OS_DISPLAY_HANDLE HWND
#else
#define ALLEGRO_OS_DISPLAY_HANDLE FOO
#endif

ALLEGRO_OS_DISPLAY_HANDLE *hndl = al_get_display_oshandle();
ShowWindow(hndl, SW_RESTORE);

or

struct ALLEGRO_OS_DISPLAY_HANDLE {
}

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle();
ShowWindow(hndl.hwnd, SW_RESTORE);

or

typedef void * ALLEGRO_OS_DISPLAY_HANDLE;

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle();
ShowWindow(hndl, SW_RESTORE);

I just don't see any point to introducing a special Allegro type when we know the only purpose is for it to be used with a platform dependent function.

Quote:

al_get_display_handle( ALLEGRO_SYSTEM_DRIVER *driver ). Maybe that is not the correct way to go, but that was my main idea.

That doesn't work, because there can be multiple displays.

Elias
Member #358
May 2000

Quote:

Also, I was thinking that maybe we could have OS specific stuff exposed by including the OS specific headers, like the old API. If you need/want Windows specific stuff for some obscure reason, then just include <allegro5/winalleg.h> or such.

That's also what I would prefer. As Matthew said, something like ALLEGRO_OS_DISPLAY_HANDLE would be entirely useless.

Quote:

On the note of a clipboard addon, what would you like to see in it? I was thinking of text, graphics, sound, and user defined types. There are a shit ton of different types in Windows, but those are the most basic. Any suggestions/ideas?

I think a function to just retrieve and set text would be a good start, once we have that people can start implementing it for different platforms.

I also can see the usefulness of pictures. But I think it should be separate pair of functions. The pictures would be converted to/from Allegro format.

All other types likely should be OS specific functions - trying to wrap too much into a cross-platform function will only make it hard to use.

--
"Either help out or stop whining" - Evert

Don Freeman
Member #5,110
October 2004
avatar

If it was an Allegro type, I would do as you posted:

#ifdef WINDOWS
#define ALLEGRO_OS_DISPLAY_HANDLE HWND
#else
#define ALLEGRO_OS_DISPLAY_HANDLE FOO
#endif
ALLEGRO_OS_DISPLAY_HANDLE *hndl = al_get_display_oshandle()

That would be more readable than casting everywhere.

Using the following, you would still have to cast somewhere in the code:

typedef void * ALLEGRO_OS_DISPLAY_HANDLE;

ALLEGRO_OS_DISPLAY_HANDLE hndl = al_get_display_oshandle()
ShowWindow((HWND)hndl, SW_RESTORE);

I'm not sure about the other systems, do they all have the same kind of functionality...a 'handle' to a window?!???

Edit:
You beat me...;D

Quote:

All other types likely should be OS specific functions - trying to wrap too much into a cross-platform function will only make it hard to use.

I don't think it will be too hard to add sound and graphics in a cross platform way. It shouldn't make a difference to the end user, the way I was going to expose the functionality. I had planned to have functions to convert an ALLEGRO_CLIPBOARD_DATA object to the various Allegro types...ALLEGRO_BITMAP and ALLEGRO_SAMPLE so ideally, that should not be a big deal to the user.

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Evert
Member #794
November 2000
avatar

Quote:

Now I'm just confused. What good is ALLEGRO_OS_DISPLAY_HANDLE? What functions would receive it?

You surprise me. You just failed basic reading. Just re-read what I said above:

I said:

I realised after posting about it that there's no need for something like that: Allegro internally knows what the OS handle on the current display is, so there would never be a good reason to specify it manually in that case.

So no, there would never be any point in having a function like that.

Quote:

Then there could be an added function to call, such as al_get_display_handle( ALLEGRO_SYSTEM_DRIVER *driver ). Maybe that is not the correct way to go, but that was my main idea.

Check allegro5/addons/native_dialog/win_dialog.c. It does the following, which I suppose from the code and comments to be similar to what you need:

[...]
#include "allegro5/platform/aintwin.h"
[...]
void al_show_native_file_dialog(ALLEGRO_NATIVE_FILE_DIALOG *fd)
{
   OPENFILENAME ofn;
   ALLEGRO_DISPLAY_WIN *display;
[...]
   display = (ALLEGRO_DISPLAY_WIN*)al_get_current_display();
   ofn.hwndOwner = display->window;

This is the proper way to do it (at the moment): if you need the platform specific information, you include the header that defines the platform-specific data structures (which are derived from Allegro's public platform-neutral data structures), cast it and then access the fields you need.

Aside and note to self: the OS X port doesn't allow you to do the same for its displays at the moment because the ALLEGRO_DISPLAY_OSX_WIN struct, which should maybe lose the _WIN, is in a different file (src/macosx/osxgl.m). That should possibly change.

EDIT: I forgot to say:

Quote:

On the note of a clipboard addon, what would you like to see in it? I was thinking of text, graphics, sound, and user defined types. There are a shit ton of different types in Windows, but those are the most basic. Any suggestions/ideas?

Don't make things too complicated (personally, I don't like seeing yet-another-datatype). I would just add functions to grab text/bitmap/sample from the clipboard and to place them there.

Elias
Member #358
May 2000

Quote:

I don't think it will be too hard to add sound and graphics in a cross platform way. It shouldn't make a difference to the end user, the way I was going to expose the functionality. I had planned to have functions to convert an ALLEGRO_CLIPBOARD_DATA object to the various Allegro types...ALLEGRO_BITMAP and ALLEGRO_SAMPLE so ideally, that should not be a big deal to the user.

Well, I don't know. I'd like if I can just do:

al_set_clipboard_text("abc");
ALLEGRO_USTR *text = al_get_clipboard_text();

Will be hard enough getting that implemented for the 3 platforms.

For pictures, I'd like something like:

al_set_clipboard_bitmap(screenshot);

Of course, if there really is use for going the way of ALLEGRO_CLIPBOARD_DATA, I won't oppose it. Can you give an example where I could do something with that I couldn't with the simple functions? I only see how it would be useful in Windows-specific code - but for that just make a Windows-specific function.

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

Quote:

You surprise me. You just failed basic reading. Just re-read what I said above:

Your post was confusing to me, because the first half plainly says you want the al_get_display_oshandle() function and the second half says you do not want some function referenced by pronouns and quotes with no citations.

But it seems we all agree now that neither al_get_display_oshandle() nor a special data type is needed.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

Of course, if there really is use for going the way of ALLEGRO_CLIPBOARD_DATA, I won't oppose it.

I think the only reason would be to support custom data formats.. but then we could do this instead:

al_set_clipboard_data(char *type, void *data);

where type is a mime type or something similar (I think most systems use mime types for clipboard data, but I'm not 100% sure about that).

edit:

Quote:

But it seems we all agree now that neither al_get_display_oshandle() or a special data type is needed.

Indeed, I didn't think far enough to realize the same thing. Any code that wants to access the handles, can do so if they grab the OS specific display type.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Don Freeman
Member #5,110
October 2004
avatar

Thanks Evert! That looks good.8-)

Quote:

Don't make things too complicated (personally, I don't like seeing yet-another-datatype). I would just add functions to grab text/bitmap/sample from the clipboard and to place them there.

The main reason for adding the ALLEGRO_CLIPBOARD_DATA type was for easier cross platform programming....a layer of abstraction that the end user would not have to know about or deal with. Should there maybe be an ALLEGRO_CLIPBOARD object that has a vtable that would point to the OS specific functions for the different ops, such as loading/saving text/graphics?

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

The main reason for adding the ALLEGRO_CLIPBOARD_DATA type was for easier cross platform programming.

The type isn't needed. Just a set of functions that can set or get ALLEGRO types.

Quote:

Should there maybe be an ALLEGRO_CLIPBOARD object that has a vtable that would point to the OS specific functions for the different ops, such as loading/saving text/graphics?

You can implement it that way, but its nothing you need to export.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Don Freeman
Member #5,110
October 2004
avatar

Ok...that sounds cool with me. <heads to evil lair to begin work.>8-)

--
"Everyone tells me I should forget about you, you don’t deserve me. They’re right, you don’t deserve me, but I deserve you."
"It’s so simple to be wise. Just think of something stupid to say and then don’t say it."

Matthew Leverton
Supreme Loser
January 1999
avatar

I agree with Elias here. I think a few functions like this are all we need:

al_set_clipboard_text(char *text);
al_set_clipboard_bitmap(ALLEGRO_BITMAP *bmp);
al_set_clipboard_data(char *type, void *data);

That would work well with Windows, at least. (Custom clipboard types are just specified by strings that you register in the registry.)

Evert
Member #794
November 2000
avatar

Quote:

Your post was confusing to me, because the first half plainly says you want the al_get_display_oshandle() function

Ah. Well, no, that was only meant as an explanation of what I meant before.

Quote:

But it seems we all agree now that neither al_get_display_oshandle() nor a special data type is needed.

Yes.

Quote:

You can implement it that way, but its nothing you need to export.

I'd follow the approach of the file selector addon: just have different files for each platform and compile the proper one in. You really only need a vtable if you think you might have different drivers for the same functionality on one platform.

Thomas Fjellstrom
Member #476
June 2000
avatar

Quote:

I'd follow the approach of the file selector addon: just have different files for each platform and compile the proper one in. You really only need a vtable if you think you might have different drivers for the same functionality on one platform.

Thats what I was thinking.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730



Go to: