AutoHotkey Community

Hi,

It seems that XP won't properly update fonts in
EXTERNAL WINDOWS controls using ahk.

I have used all sorts of ways to get a font handle
or create a font, [myhfont], and they all work on W98,
and maybe Vista, but I would like someone to verify this.
But never in XP. I have tried on 2 XP machines,

I use WM_SETFONT - 0x30 to try to set the font
in the EXTERNAL WINDOWS controls.

SendMessage, 0x30, myhFont, 1, Control, Wintitle

In XP, it just makes the font bold, but never increases
the font size.

Maybe there is a different way to do the WM_SETFONT part,
like a dllcall, a COM call ?

Maybe a separate exe in C or something could be made?

Is this an ahk bug, or an insurmountable limitation of XP?
Vista?

Any ideas how get around this would be very appreciated.

Thanks

Perhaps a font handle created/retrieved in one process isn't valid/compatible with any other process. Unlike HWNDs -- which seem to be universally valid -- perhaps HFONTs are more like memory addresses.

Hi Chris,

Would that be an XP only thing. It works in W98. Could you see if it
works in Vista?

Also, it is changing the font a little.



Also this works in W98:

hFont := DllCall("CreateFont", int,30
, int,0
, int,0
, int,0
, int,646
, int,0
, uint,0
, uint,0
, uint,0
, uint,0
, uint,0
, uint,0
, uint,0
, str, "Arial")

SendMessage, 0x30, hFont, 1, SysTabControl321, ahk_class HH Parent

I mainly need right now to change the fonts for the chm hh.exe htmlhelp
window controls.

Hey Chris,

You are on to something here. I compiled a chm file with a 30 font
in the SysTreeView321, and then used:

SendMessage, 0x31, 0, 0, SysTreeView321, ahk_class HH Parent
hFont = %ErrorLevel%

and then:

SendMessage, 0x30, hFont, 1, SysTabControl321, ahk_class HH Parent
WORKED! It made the Tabs very large.

So, to make this work universally, we need to use CreateFont somehow
be part of the hh.exe or hhctrl.ocx or other chm or XP process - "memory addresses".
Any ideas how to do that ?

Chris, could you please see if Vista works directly with WM_SETFONT
like W98 does.

For XP, do you think it will be possible to apply a font to an external
windows "memory addresses" ? Would not a function to allow this
be a good thing to add to ahk's bag of tricks?

Thanks

As WM_SETFONT < 0x400, the system will take care of all the necessary stuffs across process boundary. So, you don't have to worry about it unless a bug is in that procedure.

Thanks Sean,

Sorry if I don't get it yet. Could you please elaborate.

So are you saying I can use a simple CreateFont, and take the
hfont from it, and do something to it, to get it to work with an
External Windows controls using WM_SETFONT - 0x31 ?

Would I have do this for Vista. W98 works straight away with
hfont. I need to check on if Vista does too, but I don't have a
Vista yet. I have 2 XP's that won't change the font, and other
posters do too. It's a problem for XP in general, with many
different apps.

I suppose so as there is no mention that it cannot be used across process boundary in the MSDN doc. I suggest to test applying the (large) hFont you got (via WM_GETFONT) from your new compiled chm file to a control of AHK's GUI in the same script.

Hi Sean,
I tried WM_GETFONT on my large font, and applied it to an ahk GUI
control ON XP, and it did the same
thing that happens on the problem I am reporting, it made the font
small and bold. Just what happens cross process using CreateFont
and applying it to External Windows controls.

Now my test above does show that if you get the font from the same
process, you can apply it other controls in that same process.
So the challange is to apply fonts cross process. Or see some of my other
ideas listed above.


Try this from svi on this other thread:
http://www.autohotkey.com/forum/viewtop ... 579#265579
At first, I thought it was a chm hh.exe etc problem, but it is pandemic
on external controls in XP. W98, no problem. Vista, I wish someone
could test that for me. I don't have one. Just a W98, and 2 XPs which
both exihibit the same cross process font problem. Both XP have all the
update for XPSP2. One is XP Professional Version 2002 Service Pack 2,
and the other is XP Home Edition Version 2002 Service Pack 2

Think COM could help ?



Thanks

I see. I'm also interested in hearing about the result on Vista as I don't know if it's a generic policy in NT or just slipped off in XP.
USER/GDI objects are tricky/picky, as they are not only tied to a process, but some ones are also tied to a thread. But I don't really know whether hFont has a thread affinity or not.
I just expected WM_SETFONT to behave similarly to WM_SETICON which works well across process boudary (:hIcon doesn't have a thread affinity, AFAIK), but looks like not. I'm now wondering if there exists an API, even undocumented one, like DuplicateHandle for kernel objects...

As even COM can't (or simply doesn't?) marshal hDC which is another GDI object, I suppose not.

Hi Sean,

Well thanks for comfirming my sanity anyway. I have been chasing
this problem for years, and totally for the past 2 weeks. I just wanted
to finish my help viewer for an enlarged font app.

The problem is even more pandemic than I thought. It even affects
2 ahk scripts and ahk GUI controls. I tried running the above test as a
separate ahk script process, and running another ahk script process to
create the ahk GUI controls. Lo and behold, that does not work either. It
makes that same small Bold font. "svi" stated that it is a System font in
the other post I made.

I suspect it was slipped into XP with one of those "security" updates.
I really need to know about Vista though. Although even if Vista works
now, it's probably only 1 security update away from not working there
too.

Nobody has a Vista out there ?

Thanks

If only solving your problem with hh.exe is an issue, you may create the font in the process of hh.exe, then send WM_SETFONT. To do this, use CreateFontIndirectA via CreateRemoteThread. I wrote an example of CreateRemoteThread sometime ago:
http://www.autohotkey.com/forum/topic16575.html

PS. Hmm, it may be difficult as CreateFontIndirectA resides in gdi32.dll, not in kernel32.dll, as base address is not fixed across processes, but not impossible I suppose.

Sean, you are da man.

I wish I was 30 years younger though. I use ahk as it was a fairly
high level language. For the most part it is because of guys like
you who provide #Includes or almost ready-made functions.

But this problem is so pandemic for AHK that I think that Chris should
pay you to fix it with a nice function or include "thingy" and maybe even
add it the ahk core.

The link you gave me seems like it could maybe be a general answer
to not just my need, but why not any external process? Just feed the
hwnd or ahk_class of the external window to the first line of your code.

Also include in the function to detect if the simple way can be used. Ie:
W98, and yet to be determined Vista, future Vista versions, 2000, Me,
NT etc.

Also include in the function the inputs to specify the font characteristics
options possible. Put the big 3 first so the rest can be left out.
(height, boldness, font name)
So the function might be SeanFont(hwnd, height, bold, font, others="", ... )

Also include in the function if the function can even be run apparently,
and maybe even "set" this SetDebugPrivilege() after detecting if it is
possible/prudent to.

Also I want to ask, will all this work in a compiled ahk exe to be
distrubuted to the general public including all Windows versions.

This would plug a "gapeing" hole in ahk. IMHO.

Thanks

I sent PM to you including the code. Hope it work too in your system.

bump

is there a way to do this?

CreateFont() doesn't seem to have a parameter to change the color..