[djohnson]

Anyone have a link or code on how to do this? I have searched Apple's website, but cannot find anything useful... Hope someone can help! Thanks!

[djohnson]

How do I use:

WindowRef window;

Basically, how do I set a window to this?

[djohnson]

What I really mean: Is there a function in carbon that will return the current windows? I can set them to a WindowRef no problem if I know the function. Thanks!

[JNI]

Originally posted by djohnson:
Anyone have a link or code on how to do this? I have searched Apple's website, but cannot find anything useful... Hope someone can help! Thanks!

I don't mean to be rude, but are you kidding?

First, you can just create an example by using the Carbon Application templates in Xcode/ProjectBuilder/CodeWarrior. There are over 20 example apps in in the /Developer/Examples/Carbon directory. And of course there is the whole Carbon documentation section at the developer.apple.com site, specifically the User Experience section that has the Window Manager reference.

I mean really, where *did* you look? The info is all over the place.

[JNI]

Originally posted by djohnson:
What I really mean: Is there a function in carbon that will return the current windows? I can set them to a WindowRef no problem if I know the function. Thanks!

Are you talking about getting references to existing windows?

How about:

GetWindowList
GetNextWindow
GetPreviousWindow
FrontWindow

You can get Windows by other means too, like:

GetIndexedWindow
GetWindowOfClass

What else are you you looking for? Maybe a more specific question would help.

[djohnson]

Well to be truthful... I spent 5 minutes looking Now that I have spent 1 hour, I found:

WindowRef window = GetWindowList ();

This should work, oh and here is the url incase someone else wants to know:

http://developer.apple.com/documenta...ger/index.html

Sorry I answered my own question again!

[djohnson]

You want another question? Here is one:

How do you get the title of a window?

[JNI]

Originally posted by djohnson:
You want another question? Here is one:

How do you get the title of a window?

How about:

CopyWindowTitleAsCFString

Do you just not like to read through APIs?

[djohnson]

LOL!!! 3rd one down on the link I posted above! It is not that I dont like to read API's, it is the fact that I have been reading on these for hours today. Oh and I am learning Carbon at the same time.

[BrandonCorbin]

GOD I LOVE THIS PLACE... restraining from making a rude comment towards specific kind of members of this site...

[djohnson]

Thank you again.

Here is some code that is being called in a carbon application:

<b>
WindowRef window;

window = FrontWindow();
if(!IsValidWindowPtr(window))
{
fprintf(stderr, "Error, window is not a valid ptr!\n");
}
else
{
fprintf(stderr, "Pointer is good");
}
</b>

It always returns "Error, window is not a valid ptr!" Why is this???

[JNI]

Originally posted by djohnson:
Thank you again.

Here is some code that is being called in a carbon application:

<b>
WindowRef window;

window = FrontWindow();
if(!IsValidWindowPtr(window))
{
fprintf(stderr, "Error, window is not a valid ptr!\n");
}
else
{
fprintf(stderr, "Pointer is good");
}
</b>

It always returns "Error, window is not a valid ptr!" Why is this???

That snippet works for me. Obviously there has to be a visible and active window, otherwise FrontWindow will just return NULL. Is it returning NULL or some non-null value?

More context might be needed to figure out what you're doing wrong.

[JNI]

Originally posted by BrandonCorbin:
GOD I LOVE THIS PLACE... restraining from making a rude comment towards specific kind of members of this site...

Care to elaborate?

[BrandonCorbin]

Originally posted by JNI:
Care to elaborate?

Not really. Im glad to see this thread working out. Brandon

[djohnson]

Well I figured out the code wont allow for me to get the windows... I dont know why either. Thanks though!

[JNI]

Originally posted by djohnson:
Well I figured out the code wont allow for me to get the windows... I dont know why either. Thanks though!

You're giving up? That's no fun!

[djohnson]

Originally posted by JNI:
You're giving up? That's no fun!

I am not giving up as much as it will not work. The window pointer cannot be declared in my current function. I did get a work around working though. If you have any other ideas, please share!

[JNI]

Originally posted by djohnson:
I am not giving up as much as it will not work. The window pointer cannot be declared in my current function. I did get a work around working though. If you have any other ideas, please share!

Now I'm confused. What do you mean the window pointer 'can't be declared'. You 'declared' it in your snippet - you just said that FrontWindow wasn't returning a valid pointer. The only way a WindowRef type wouldn't be able to be declared is if you didn't include the appropriate header files or libraries. That would be a compile time error, not a run time error, as your snippet post implied.

If you create a simple example app using a template project, you can verify that FrontWindow works as it should. So there must be something that you are doing that your not telling us. I mean, come on, FrontWindow has been a basic function in the Mac API since OS 1.0.

More info is needed. Do you have an existing project that you are trying to modify? Did you start with a template project? Are you trying to mix Carbon and Cocoa? What error is being reported that you interpret as not allowing the window pointer to be declared? What value is returned from FrontWindow? Do you have a visible and active window? What tools are you using?

As I said, your basic snippet works for me. So you need to post more contextual information for anyone to determine why it is not working for you.

[BrandonCorbin]

JNI, lets just say that we wanted to load a bundle of code in to every application using unsanity's APE. We then want every application to send a notification of when a new window is displayed or closed for that matter to a master application. He is trying to get a window name basically for all windows that said application has, weather it be in cocoa or carbon. Im not a developer by any stretch, more of an architect if you will. but if this helps understand what djohnson is trying to, then im glad to do it.

[JNI]

Originally posted by BrandonCorbin:
JNI, lets just say that we wanted to load a bundle of code in to every application using unsanity's APE. We then want every application to send a notification of when a new window is displayed or closed for that matter to a master application. He is trying to get a window name basically for all windows that said application has, weather it be in cocoa or carbon. Im not a developer by any stretch, more of an architect if you will. but if this helps understand what djohnson is trying to, then im glad to do it.

Let's just say, for something like a Taskbar application?

I know that FrontWindow works for true Carbon applications. AFAIK it won't work in Cocoa applications. So at minimum you would need to know which type of app you're APE'ing first. I also know that you can't access the Carbon WindowList from outside an application, since the memory will be in a different VM space (but I presume an APE module runs in the VM space of the app it is APE'ing.) Other than that, I don't know enough about APE to make any more suggestions.

If djohnson had mentioned the APE thing in the first place, this thread would probably have taken a very different tack. I'd say that was a pretty important part of the missing context.

Sounds like questions for the carbon-development and codoa-dev lists, or better yet if there are any APE specific support forums.

[BrandonCorbin]

Amazingly enough there are almost no forums for APE.. Driving me nuts. See we have the CGS working fine, but I think we could do some cool stuff with APE, but its obviously has its problems, and there just isnt enough information out there for it. So I think its going to have to be the CGS way, which will work great.

thanks for your help.
B

[djohnson]

My bad. I was trying both in APE and not in APE. I dont like APE Thanks for the help though! It did help getting ShowWindow(WindowRef window); I could manipulate the window no problem with that. I think I was trying to get a WindowRef when there was no window present, ie before ShowWindow() was called!!!

BTW, if anyone cares, CGS is great fun stuff!!!

[JNI]

Originally posted by djohnson:
I think I was trying to get a WindowRef when there was no window present, ie before ShowWindow() was called!!!

So then in fact, FrontWindow was working as it should and telling you exactly the truth - there was no front window. How 'bout that!

[djohnson]

Originally posted by JNI:
So then in fact, FrontWindow was working as it should and telling you exactly the truth - there was no front window. How 'bout that!

Bah

[Angus_D]

BTW you shouldn't expect FrontWindow to always return what you expect it to - if there's menu tracking going on I think it can return a menu's WindowRef in 10.3, and there was some discussion about it possibly returning the menubar's WindowRef in 10.4... Anyway, it's just bad and not recommended.

[JNI]

Originally posted by Angus_D:
BTW you shouldn't expect FrontWindow to always return what you expect it to - if there's menu tracking going on I think it can return a menu's WindowRef in 10.3, and there was some discussion about it possibly returning the menubar's WindowRef in 10.4... Anyway, it's just bad and not recommended.

I thought that had been resolved. I remember some 'potential heads up' stuff on the carbon-dev list, and due to the feedback they got, Apple decided it would break too much if they changed the way FrontWindow worked, so they planned on special casing the internal code so that it would act externally as existing applications expected for the sake of compatibility. I haven't kept up with that thread recently though, so I may not have all the current information. I think it would be best to pursue this kind of thing on the official carbon-dev list.

[Angus_D]

Originally posted by JNI:
I thought that had been resolved. I remember some 'potential heads up' stuff on the carbon-dev list, and due to the feedback they got, Apple decided it would break too much if they changed the way FrontWindow worked, so they planned on special casing the internal code so that it would act externally as existing applications expected for the sake of compatibility. I haven't kept up with that thread recently though, so I may not have all the current information. I think it would be best to pursue this kind of thing on the official carbon-dev list.

I think they decided on special-casing it for the menubar, but it'll still break with menu tracking on 10.3, and I remember there was a recommendation against using it (and using something else instead) because of issues like this. I'm not really a Carbon developer, so...

[JNI]

Originally posted by Angus_D:
I think they decided on special-casing it for the menubar, but it'll still break with menu tracking on 10.3, and I remember there was a recommendation against using it (and using something else instead) because of issues like this. I'm not really a Carbon developer, so...

I think the problem comes from the change in 10.3 where menus are now derived from the Window class. That was not the case previously, and especially not in Classic applications.

Since in the cooperatively threaded Carbon/Classic world it wouldn't normally be a problem because MenuSelect is a modal call, and therefore the only way it would be a problem is if you tried to use FrontWindow (or other accesses to the WindowList) from within a custom menu tracking hook, which would be highly unusual. But in a multi-threaded world, a different thread could try to use FrontWindow while MenuSelect was in progress and the menu was open.

I imagine there must be some way to test a WindowRef and maybe look at its WDEF ID or something like that to see if it was a true user document window as opposed to probably some special WDEF ID used for menu 'windows.'

So for djohnson, where I believe he is running his code in a separate thread from the Carbon app's main event thread (via APE or something like that), yes that could be a problem. He should head over to the carbon-dev list to figure out how to cope with that case.

[Angus_D]

Originally posted by JNI:
I think the problem comes from the change in 10.3 where menus are now derived from the Window class. That was not the case previously, and especially not in Classic applications.[

They have always been windows as far as the windowserver is concerned, it's just that they now have WindowRefs so they're windows as far as the high-level frameworks are concerned too.

I imagine there must be some way to test a WindowRef and maybe look at its WDEF ID or something like that to see if it was a true user document window as opposed to probably some special WDEF ID used for menu 'windows.'

As I said, there was code posted in that thread for getting the front window of document class. This was recommended as an alternative to FrontWindow().