Menu
▾
▴
perl-win32-gui-users
|
From: Ilya B. <Ily...@so...> - 2009-04-21 15:27:43
|
Hello to everybody! I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI? Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any _correct_ way to determine if XP styles are active and draw controls correctly? Thank you in advance! Regards, Ilya |
|
From: Jason P. <ma...@wa...> - 2009-04-21 16:47:58
|
If you a search the lest you should find reference to the small file that needs to be added so that the programs via perl will all use default XP styles, search for "XP" and "manifest" 2009/4/21 Ilya BANDORIN <Ily...@so...> > Hello to everybody! > > > > I'm just interested if dear developers have any plans to introduce XP > styles support to Win32::GUI? > > Being compiled with ActiveState's PerlApp the application runs with XP > styles but tabstrip control drives me crazy because all other controls being > placed on the tabstrip still have gray background while the tabstrip's > background is different (white). Are there any _*correct*_ way to > determine if XP styles are active and draw controls correctly? > > > > Thank you in advance! > > > > > > Regards, > > Ilya > > > > ========================================================= > > Ce message et toutes les pieces jointes (ci-apres le "message") > sont confidentiels et susceptibles de contenir des informations > couvertes par le secret professionnel. Ce message est etabli > a l'intention exclusive de ses destinataires. Toute utilisation > ou diffusion non autorisee interdite. > Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE > et ses filiales declinent toute responsabilite au titre de ce message > s'il a ete altere, deforme falsifie. > > ========================================================= > > This message and any attachments (the "message") are confidential, > intended solely for the addressees, and may contain legally privileged > information. Any unauthorised use or dissemination is prohibited. > E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any > of its subsidiaries or affiliates shall be liable for the message > if altered, changed or falsified. > > ========================================================= > > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Perl-Win32-GUI-Users mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users > http://perl-win32-gui.sourceforge.net/ > -- Maximus* WarheadsSE MaxSource |
|
From: Jeremy W. <jez...@ho...> - 2009-04-21 16:50:23
|
Hi, XP styles (as I understand it) is a separate "thing" from Win32::GUI and is controlled by a manifest file. This manifest file is included inside the exe by PerlApp. If you have a manifest file for Perl itself you'll get XP styles when you run your app via perl. Have a search on this list on how to do that (its simple - but I dont have the details to hand). As for the tabstrip, I have seen this in the past and I've never found a solution to it (again, I dont think it's a Win32::GUI thing). The way I have got around this is to have a grey child window covering the while background, and add the controls to the child window. Works well... Cheers, Jeremy. Date: Tue, 21 Apr 2009 19:28:57 +0400 From: Ily...@so... To: per...@li... Subject: [perl-win32-gui-users] XP styles support -- when? Hello to everybody! I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI? Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any _correct_ way to determine if XP styles are active and draw controls correctly? Thank you in advance! Regards, Ilya ========================================================= Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential, intended solely for the addressees, and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ========================================================= _________________________________________________________________ View your Twitter and Flickr updates from one place – Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/ |
|
From: Jan D. <ja...@ac...> - 2009-04-21 22:16:45
|
Do you guys (users of Win32-GUI) have an opinion of perl.exe always requesting XP style controls? I think perl.exe needs an embedded manifest to properly specify the requested elevation level on Windows Vista and later. Once that happens it will no longer be possible to request XP style controls simply by putting a manifest into perl.exe.manifest because the mebedded manifest will take precedence. So what do you think, should perl.exe in that case request the XP style controls or not? Cheers, -Jan From: Jeremy White [mailto:jez...@ho...] Sent: Tuesday, April 21, 2009 9:50 AM To: ily...@so...; per...@li... Subject: Re: [perl-win32-gui-users] XP styles support -- when? Hi, XP styles (as I understand it) is a separate "thing" from Win32::GUI and is controlled by a manifest file. This manifest file is included inside the exe by PerlApp. If you have a manifest file for Perl itself you'll get XP styles when you run your app via perl. Have a search on this list on how to do that (its simple - but I dont have the details to hand). As for the tabstrip, I have seen this in the past and I've never found a solution to it (again, I dont think it's a Win32::GUI thing). The way I have got around this is to have a grey child window covering the while background, and add the controls to the child window. Works well... Cheers, Jeremy. _____ Date: Tue, 21 Apr 2009 19:28:57 +0400 From: Ily...@so... To: per...@li... Subject: [perl-win32-gui-users] XP styles support -- when? Hello to everybody! I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI? Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any _correct_ way to determine if XP styles are active and draw controls correctly? Thank you in advance! Regards, Ilya ========================================================= Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et susceptibles de contenir des informations couvertes par le secret professionnel. Ce message est etabli a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee interdite. Tout message electronique est susceptible d'alteration. La SOCIETE GENERALE et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential, intended solely for the addressees, and may contain legally privileged information. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ========================================================= _____ Surfing the web just got more rewarding. Download the New Internet Explorer 8 <http://extras.uk.msn.com/internet-explorer-8/?ocid=T010MSN07A0716U> |
|
From: Glenn L. <pe...@Ne...> - 2009-04-22 00:30:22
|
On approximately 4/21/2009 3:16 PM, came the following characters from the keyboard of Jan Dubois: > Do you guys (users of Win32-GUI) have an opinion of perl.exe always > requesting XP style controls? > > > > I think perl.exe needs an embedded manifest to properly specify the > requested elevation level on Windows Vista and later. Once that happens > it will no longer be possible to request XP style controls simply by > putting a manifest into perl.exe.manifest because the mebedded manifest > will take precedence. > > > > So what do you think, should perl.exe in that case request the XP style > controls or not? Well, what happens on WinNt sp4 or Win2k? If they totally ignore the manifest, and things still work, then I have no problem with programs on XP looking different... But my understanding is that some of the controls work different, and so things might not work? (I know there are several Open dialogs that have different parameters and results, for example.) If that is the case, then it would seem that requesting XP style controls should only be done when the programmer says that is a good idea, and can handle both cases. As far as Vista is concerned, if it needs separate malarky to operate, then there ought to be a way to obtain that malarky separately, even if it means a separate version of Perl to access the Vista-specific features. Everything I've read about this "assembly" stuff sounds like sophisticated nonsense to me, and has given me more desire to keep running XP, and keep recommending XP to my clients. When the day comes that XP-developed programs won't work in Windows-Assimilation version, I'll start recommending Linux. -- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking |
|
From: Jeremy W. <jez...@ho...> - 2009-04-22 17:21:02
|
I vote for adding the XP style request directly to perl.exe - in almost all cases it's the "correct" thing to do and is easy enough to remove (and indeed from PerlApp) should you need to. It's also backward compatible so it wont harm Win 2000 users etc. Cheers, Jeremy. From: ja...@ac... To: jez...@ho...; ily...@so...; per...@li... Subject: RE: [perl-win32-gui-users] XP styles support -- when? Date: Tue, 21 Apr 2009 15:16:37 -0700 Do you guys (users of Win32-GUI) have an opinion of perl.exe always requesting XP style controls? I think perl.exe needs an embedded manifest to properly specify the requested elevation level on Windows Vista and later. Once that happens it will no longer be possible to request XP style controls simply by putting a manifest into perl.exe.manifest because the mebedded manifest will take precedence. So what do you think, should perl.exe in that case request the XP style controls or not? Cheers, -Jan From: Jeremy White [mailto:jez...@ho...] Sent: Tuesday, April 21, 2009 9:50 AM To: ily...@so...; per...@li... Subject: Re: [perl-win32-gui-users] XP styles support -- when? Hi, XP styles (as I understand it) is a separate "thing" from Win32::GUI and is controlled by a manifest file. This manifest file is included inside the exe by PerlApp. If you have a manifest file for Perl itself you'll get XP styles when you run your app via perl. Have a search on this list on how to do that (its simple - but I dont have the details to hand). As for the tabstrip, I have seen this in the past and I've never found a solution to it (again, I dont think it's a Win32::GUI thing). The way I have got around this is to have a grey child window covering the while background, and add the controls to the child window. Works well... Cheers, Jeremy. Date: Tue, 21 Apr 2009 19:28:57 +0400 From: Ily...@so... To: per...@li... Subject: [perl-win32-gui-users] XP styles support -- when? Hello to everybody! I'm just interested if dear developers have any plans to introduce XP styles support to Win32::GUI? Being compiled with ActiveState's PerlApp the application runs with XP styles but tabstrip control drives me crazy because all other controls being placed on the tabstrip still have gray background while the tabstrip's background is different (white). Are there any _correct_ way to determine if XP styles are active and draw controls correctly? Thank you in advance! Regards, Ilya ========================================================= Ce message et toutes les pieces jointes (ci-apres le "message")sont confidentiels et susceptibles de contenir des informationscouvertes par le secret professionnel. Ce message est etablia l'intention exclusive de ses destinataires. Toute utilisationou diffusion non autorisee interdite.Tout message electronique est susceptible d'alteration. La SOCIETE GENERALEet ses filiales declinent toute responsabilite au titre de ce messages'il a ete altere, deforme falsifie. ========================================================= This message and any attachments (the "message") are confidential,intended solely for the addressees, and may contain legally privilegedinformation. Any unauthorised use or dissemination is prohibited.E-mails are susceptible to alteration. Neither SOCIETE GENERALE nor anyof its subsidiaries or affiliates shall be liable for the messageif altered, changed or falsified. ========================================================= Surfing the web just got more rewarding. Download the New Internet Explorer 8 _________________________________________________________________ View your Twitter and Flickr updates from one place – Learn more! http://clk.atdmt.com/UKM/go/137984870/direct/01/ |
|
From: Rob M. <ro...@th...> - 2009-04-22 18:57:59
|
2009/4/22 Jeremy White <jez...@ho...>: > I vote for adding the XP style request directly to perl.exe - in almost all > cases it's the "correct" thing to do and is easy enough to remove (and > indeed from PerlApp) should you need to. It's also backward compatible so it > wont harm Win 2000 users etc. I think I vote for it too, although I suspect that it'll cause some (minor) layout problems for some people, as I'm not sure that all the control decorations are the same on styled/non-styled controls. Last time I had some time to play (sadly I don't get much of that these days) I was looking at adding a manifest to GUI.dll - it's possible to add a manifest to a DLL and get the version 6 controls for any windows created by that DLL, even if the main APP doesn't have a manifest; however this depends on some stuff that's in the MS headers, and doesn't work with the mingw headers (and hence won't work with cygwin). I have a patch somewhere (but not with me at the moment). There are also some API calls that can be used to turn styling on and off on a per-app and per-window basis, once you've got the v6 controls loaded ..... I haven't yet come up with a suitable strategy for introducing this thought; perhaps adding a v6 manifest to perl.exe will force me to find time to investigate further? I hope to find some time to get back to Win32::GUI development over the summer. Rob. |
|
From: Jan D. <ja...@ac...> - 2009-04-22 19:41:46
|
On Wed, 22 Apr 2009, Rob May wrote: > 2009/4/22 Jeremy White <jez...@ho...>: > > I vote for adding the XP style request directly to perl.exe - in > > almost all cases it's the "correct" thing to do and is easy enough > > to remove (and indeed from PerlApp) should you need to. It's also > > backward compatible so it wont harm Win 2000 users etc. What exactly is the "easy" way to remove the new style common controls from an app that requests them in an embedded MANIFEST? On XP itself you can provide an external perl.exe.manifest that would override the embedded one, but on 2003, Vista, 2008 the embedded one always takes precedence. So you'll need to actually remove the embedded manifest with a tool like mt.exe, but that is only available as part of the Windows Platform SDK, so I would not really call it "trivial". > I think I vote for it too, although I suspect that it'll cause some > (minor) layout problems for some people, as I'm not sure that all the > control decorations are the same on styled/non-styled controls. There are some layout differences, so it will be visible in some apps. > Last time I had some time to play (sadly I don't get much of that > these days) I was looking at adding a manifest to GUI.dll - it's > possible to add a manifest to a DLL and get the version 6 controls for > any windows created by that DLL, even if the main APP doesn't have a > manifest; however this depends on some stuff that's in the MS headers, > and doesn't work with the mingw headers (and hence won't work with > cygwin). I have a patch somewhere (but not with me at the moment). Interesting. I don't quite understand how this would work though, as the names of the controls are registered globally, so I don't see how you could mix old and new style controls inside a single process. > There are also some API calls that can be used to turn styling on and > off on a per-app and per-window basis, once you've got the v6 controls > loaded ..... I haven't yet come up with a suitable strategy for > introducing this thought; perhaps adding a v6 manifest to perl.exe > will force me to find time to investigate further? Could you find a link to some documentation about this so I can understand how this is supposed to work? Note that we'll also have to check with e.g. the wxPerl community, and probably others to hear what they think about this. Cheers, -Jan |
|
From: Jeremy W. <jez...@ho...> - 2009-04-22 22:00:27
|
> On Wed, 22 Apr 2009, Rob May wrote: >> 2009/4/22 Jeremy White <jez...@ho...>: >>> I vote for adding the XP style request directly to perl.exe - in >>> almost all cases it's the "correct" thing to do and is easy enough >>> to remove (and indeed from PerlApp) should you need to. It's also >>> backward compatible so it wont harm Win 2000 users etc. >> What exactly is the "easy" way to remove the new style common controls > from an app that requests them in an embedded MANIFEST? On XP itself > you can provide an external perl.exe.manifest that would override the > embedded one, but on 2003, Vista, 2008 the embedded one always takes > precedence. So you'll need to actually remove the embedded manifest > with a tool like mt.exe, but that is only available as part of the > Windows Platform SDK, so I would not really call it "trivial". As part of my build process I use reshacker (a free utility with a command line interface) to replace the manifest that is added with PerlApp: http://angusj.com/resourcehacker/ I think the perl module below can also replace/delete the manifest (although I haven't tried - on my todo list) http://search.cpan.org/~smueller/Win32-Exe-0.11/lib/Win32/Exe.pm As a side reshacker can also be used to add other resources to exe's (such as icons, bitmaps and string tables) and Win32::GUI automatically picks them up. Cheers, jez. _________________________________________________________________ Share your photos with Windows Live Photos – Free. http://clk.atdmt.com/UKM/go/134665338/direct/01/ |
|
From: Rob M. <ro...@th...> - 2009-04-23 16:17:31
|
2009/4/23 Jan Dubois <ja...@ac...>: > On Wed, 22 Apr 2009, Rob May wrote: >> I think I vote for it too, although I suspect that it'll cause some >> (minor) layout problems for some people, as I'm not sure that all the >> control decorations are the same on styled/non-styled controls. > > There are some layout differences, so it will be visible in some apps. Despite this I think it is the way forwards - perhaps we can find an easy way to disable it for those that don't want it? >> Last time I had some time to play (sadly I don't get much of that >> these days) I was looking at adding a manifest to GUI.dll - it's >> possible to add a manifest to a DLL and get the version 6 controls for >> any windows created by that DLL, even if the main APP doesn't have a >> manifest; however this depends on some stuff that's in the MS headers, >> and doesn't work with the mingw headers (and hence won't work with >> cygwin). I have a patch somewhere (but not with me at the moment). > > Interesting. I don't quite understand how this would work though, as > the names of the controls are registered globally, so I don't see how > you could mix old and new style controls inside a single process. I'm not going to pretend that I understand it all either, but it's certainly possible for a process to load both v5 and v6 controls and use both - I suspect that if one was to understand activation contexts in detail it's possible to have both sorts of contro; within the same window - not that I can think of a reason for doing that! My starting point was this documentation: http://msdn.microsoft.com/en-us/library/ms997646.aspx >> There are also some API calls that can be used to turn styling on and >> off on a per-app and per-window basis, once you've got the v6 controls >> loaded ..... I haven't yet come up with a suitable strategy for >> introducing this thought; perhaps adding a v6 manifest to perl.exe >> will force me to find time to investigate further? > > Could you find a link to some documentation about this so I can understand > how this is supposed to work? Per application: SetThemeAppProperties - http://msdn.microsoft.com/en-us/library/bb759825(VS.85).aspx Per window: SetWindowTheme - http://msdn.microsoft.com/en-us/library/bb759827(VS.85).aspx > Note that we'll also have to check with e.g. the wxPerl community, and > probably others to hear what they think about this. Of course. Perhaps the opposite of what I suggested above: use a v6 manifest, but turn off themes by default and provide an easy way to turn them on for those that want them? Regards, Rob. |
|
From: Jan D. <ja...@ac...> - 2009-04-23 22:18:49
|
On Thu, 23 Apr 2009, Rob May wrote: > 2009/4/23 Jan Dubois <ja...@ac...>: >> Interesting. I don't quite understand how this would work though, as >> the names of the controls are registered globally, so I don't see how >> you could mix old and new style controls inside a single process. > > I'm not going to pretend that I understand it all either, but it's > certainly possible for a process to load both v5 and v6 controls and > use both - I suspect that if one was to understand activation contexts > in detail it's possible to have both sorts of contro; within the same > window - not that I can think of a reason for doing that! > > My starting point was this documentation: > http://msdn.microsoft.com/en-us/library/ms997646.aspx > >> Could you find a link to some documentation about this so I can >> understand how this is supposed to work? > > Per application: SetThemeAppProperties - > http://msdn.microsoft.com/en-us/library/bb759825(VS.85).aspx Per > window: SetWindowTheme - > http://msdn.microsoft.com/en-us/library/bb759827(VS.85).aspx Ok, I see. You would not be missing v5 and v6 style controls; all controls will be from v6, but you would disable the styling, so they would still look like the old style. But any changes in the message handling of the controls would still be there. But I think this should be good enough. So I think perl.exe should change the manifest to always request v6 style controls, and then the Win32 module could add a function to call SetThemeAppProperties() to switch off theming if an application wants to do this. This way the function would be generally available for all users, even if the specific GUI toolkit (e.g. Perl/Tk, or gTk, or wxPerl or Tkx or whatever doesn't provide access to it). Since you said you wanted to provide access to the theming APIs in Win32-GUI in the future: these APIs are all in the uxtheme.dll, which only exists on Windows XP and later. Therefore you must not link against uxtheme.lib if you want the module to continue to work on Windows 2000; instead you need to do the LoadLibrary/GetProcAddress dance, or put the calls into a separate XS file that is only loaded on XP and later. Cheers, -Jan |
|
From: Rob M. <ro...@th...> - 2009-05-02 15:23:55
|
2009/4/22 Jan Dubois <ja...@ac...>: > On Wed, 22 Apr 2009, Rob May wrote: >> I think I vote for it too, although I suspect that it'll cause some >> (minor) layout problems for some people, as I'm not sure that all the >> control decorations are the same on styled/non-styled controls. > > There are some layout differences, so it will be visible in some apps. I've had a chance to play further, and at least on XP once the perl.exe manifest required V6 of the common controls I can find no way to get back to using the V5 controls in an extension. Theoretically is should be possible to build perl with ISOLATION_AWARE_ENABLED defined, but then all extension DLL will use V5 of the common controls, somewhat defeating the purpose of asking for them in manifest in the first place. I don't think this is a reason not to have the perl.exe manifest request v6 common controls, but thought I should mention this as a potential problem. >> Last time I had some time to play (sadly I don't get much of that >> these days) I was looking at adding a manifest to GUI.dll - it's >> possible to add a manifest to a DLL and get the version 6 controls for >> any windows created by that DLL, even if the main APP doesn't have a >> manifest; however this depends on some stuff that's in the MS headers, >> and doesn't work with the mingw headers (and hence won't work with >> cygwin). I have a patch somewhere (but not with me at the moment). The change required here is very simple. Define the C Pre-processor symbol ISOLATION_AWARE_ENABLED for the whole project, and add a v6 manifest to the resource section with resource id 2 (ISOLATION_AWARE_MANIFEST_ID); build with Visual C and the headers/system do eveything else for you. As stated above this doesn't work with mingw/gcc. As I was getting fed up with adding/removing a manifest file from the perl bin directory to test apps with and without manifests, I've written a small module that can turn on visual styles (Win32::VisualStyles). Code can be download from http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles - I'd appreciate feedback on the interface and whether it works for you. If I get positive feedback I'll finish tidying up the documentation and release it as a CPAN module. I've not put it in the Win32::GUI namespace, as I think it has wider applicability. The code creates a V6 activation context (what a manifest gets turned into) and activates it. It also provides access to the Win32 API calls S/GetThemeAppProperties, IsThemeActive, IsAppThemed, and also provides a control_styles_active() API (as the Win32 API calls don't do exactly what their names suggest they might). It should work back to perl 5.6, and should have no detrimental effects on platforms that don't support styles (pre-XP); If your perl already has a V6 manifest it spots this and doesn't change the activation context. Comments, as always, welcome. Regards, Rob. > > Interesting. I don't quite understand how this would work though, as > the names of the controls are registered globally, so I don't see how > you could mix old and new style controls inside a single process. > >> There are also some API calls that can be used to turn styling on and >> off on a per-app and per-window basis, once you've got the v6 controls >> loaded ..... I haven't yet come up with a suitable strategy for >> introducing this thought; perhaps adding a v6 manifest to perl.exe >> will force me to find time to investigate further? > > Could you find a link to some documentation about this so I can understand > how this is supposed to work? > > Note that we'll also have to check with e.g. the wxPerl community, and > probably others to hear what they think about this. > > Cheers, > -Jan > > |
|
From: Jan D. <ja...@ac...> - 2009-05-04 21:57:18
|
On Sat, 02 May 2009, Rob May wrote: > 2009/4/22 Jan Dubois <ja...@ac...>: > I've had a chance to play further, and at least on XP once the > perl.exe manifest required V6 of the common controls I can find no way > to get back to using the V5 controls in an extension. Theoretically is > should be possible to build perl with ISOLATION_AWARE_ENABLED defined, > but then all extension DLL will use V5 of the common controls, > somewhat defeating the purpose of asking for them in manifest in the > first place. > > I don't think this is a reason not to have the perl.exe manifest > request v6 common controls, but thought I should mention this as a > potential problem. The fact that you can programmatically request v6 controls without having to add a manifest is enough reason to prevent adding this part of the manifest for at least Perl 5.10.x, especially if you cannot programmatically switch back to *not* require v6. As to using v5 controls from a process that has v6 in its manifest I would try something like this: * Add a second manifest resource to your extension DLL that doesn't specify v6 controls. Use any user defined resource name you want. * Call CreateActCtx() with an ACTATC structure that has includes the resource name for this alternate manifest. * Activate this manifest. > As I was getting fed up with adding/removing a manifest file from the > perl bin directory to test apps with and without manifests, I've > written a small module that can turn on visual styles > (Win32::VisualStyles). Code can be download from > http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles - I'd > appreciate feedback on the interface and whether it works for you. If > I get positive feedback I'll finish tidying up the documentation and > release it as a CPAN module. I've not put it in the Win32::GUI > namespace, as I think it has wider applicability. I haven't tried it yet, but it looks like a good idea. +1 on separating it out from Win32::GUI. Random comments just from looking at the source: * The manifest file contains a hardcoded X86 architecture. The file should be generated dynamically and contain AMD64 as the architecture for 64-bit Windows on x86_64. Something like this: http://github.com/jandubois/perl/blob/45b29eb26a4450f83f586c2fc2e47964713cc910/win32/perlexe_manifest.PL * The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them. * I would normally just copy the required Windows SDK definitions into the *.xs file so that the code can be compiled with just VC6/MinGW and doesn't need a Windows SDK installation. * Why are you calling LoadLibraryW() instead of LoadLibraryA()? Most of the feedback above is probably just personal taste, except for the architecture string in the manifest on 64-bit Windows. I hope I'll get some time soon to actually play with it a little (e.g. see if it otherwise works on 64-bit). Cheers, -Jan |
|
From: Rob M. <ro...@th...> - 2009-05-05 08:58:43
|
2009/5/4 Jan Dubois <ja...@ac...>: > The fact that you can programmatically request v6 controls without > having to add a manifest is enough reason to prevent adding this > part of the manifest for at least Perl 5.10.x, especially if you > cannot programmatically switch back to *not* require v6. In general I agree - from the point of view of the Win32::GUI package I'm indifferent. > As to using v5 controls from a process that has v6 in its manifest > I would try something like this: > > * Add a second manifest resource to your extension DLL that doesn't > specify v6 controls. Use any user defined resource name you want. > > * Call CreateActCtx() with an ACTATC structure that has includes > the resource name for this alternate manifest. > > * Activate this manifest. I've tried this (at least on XP). (and in the process worked out most of the undocumented/badly documented parts of the ACTCTX structure). I've tried several ways (I can let you have my test code if you're interested). Under XP I can't find any way to get back from a V6 activation context to a V5 activation context. (A manifest with no dependancy on any Comctrl32 doesn't seem to do the trick; A manifest with an explicit 5.80/1/2 dependence fails to create an activation context). I haven't tried under Vista, where it might be possible to explicitly request a v5.8 comctl32.dll, as I notice that v5 comctrl32 entries in the WinSxS directory - which doesn't happen in XP. I'll try to find some time for a little further investigation, as I'm sure it should be possible - but I haven't found a way yet. >> I've written a small module that can turn on visual styles >> (Win32::VisualStyles). > I haven't tried it yet, but it looks like a good idea. +1 on separating > it out from Win32::GUI. Random comments just from looking at the source: > > * The manifest file contains a hardcoded X86 architecture. The file should > be generated dynamically and contain AMD64 as the architecture for 64-bit > Windows on x86_64. Something like this: > > http://github.com/jandubois/perl/blob/45b29eb26a4450f83f586c2fc2e47964713cc910/win32/perlexe_manifest.PL Thanks - According to the "spec" (http://msdn.microsoft.com/en-us/library/aa374191(VS.85).aspx) the processorArchitecture attribute is optional. If omitted I think it would mean all architectures. I'm pretty sure I've also seen processorArchitecture="*" - but can't find any examples/documentation immediately. I'll work out a suitable course of action and modify the manifest/ add _manifest.PL as appropriate. > * The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them. Thanks - I'll modify. > * I would normally just copy the required Windows SDK definitions into the > *.xs file so that the code can be compiled with just VC6/MinGW and doesn't > need a Windows SDK installation. I'll look at this. I always find it difficult to find suitable defines to use as guards around structure definitions, so that it also works with an SDK installation, but that's not insurmountable. > * Why are you calling LoadLibraryW() instead of LoadLibraryA()? Mainly because I 'borrowed' the code. The reality is that once we're at that point in the code we know that we've got LoadLibraryW ... and calling LoadLibraryW will be marginally faster than LoadLibraryA, which AFAICT will be a wrapper around LoadLibraryW, with a MultiByteToWideChar call. I don't think it really matters, and for the sake of not breaking a non-delay-loading build I'll change it to LoadLibraryA. > Most of the feedback above is probably just personal taste, except for the > architecture string in the manifest on 64-bit Windows. > > I hope I'll get some time soon to actually play with it a little (e.g. see > if it otherwise works on 64-bit). Many thanks for the feedback. Might this be a candidate for inclusion in libwin32 (or whatever that's become)? Rob. |
|
From: Rob M. <ro...@th...> - 2009-05-05 14:36:01
|
2009/5/5 Rob May <ro...@th...>: > 2009/5/4 Jan Dubois <ja...@ac...>: >> * The manifest file contains a hardcoded X86 architecture. The file should >> be generated dynamically and contain AMD64 as the architecture for 64-bit >> Windows on x86_64. Something like this: Manifest is now generated. >> * The SYNOPSIS uses IsThemeActive() and IsAppThemed() without importing them. Synopsis updated to show importing of IsThemeActive and IsAppThemed. >> * I would normally just copy the required Windows SDK definitions into the >> *.xs file so that the code can be compiled with just VC6/MinGW and doesn't >> need a Windows SDK installation. I reverted WINVER and _WIN32_WINNT down to 0x)400 to aviod generating wwarnings from the VC6 headers, and then added the extra stuff needed into VisualStyles.xs. This allowed me to get rid of the extra mingw.h file too. Seems to build fine for me with VC6 (SP2), VC2 (SP2) with Feb 2003 PSDK R2, mingw (gcc version 3.4.5 (mingw-vista special r3)). >> * Why are you calling LoadLibraryW() instead of LoadLibraryA()? LoadLibraryW replaced with LoadLibraryA. New source (V0.00_02) at: http://rob.themayfamily.me.uk/win32-gui/win32-visualstyles Regards, Rob. |
|
From: Jan D. <ja...@ac...> - 2009-05-05 17:00:12
|
On Tue, 05 May 2009, Rob May wrote: > 2009/5/4 Jan Dubois <ja...@ac...>: > Thanks - According to the "spec" > (http://msdn.microsoft.com/en-us/library/aa374191(VS.85).aspx) the > processorArchitecture attribute is optional. If omitted I think it > would mean all architectures. I'm pretty sure I've also seen > processorArchitecture="*" - but can't find any examples/documentation > immediately. > > I'll work out a suitable course of action and modify the manifest/ add > _manifest.PL as appropriate. If processorArchitecture="*" works, then that would be the preferred solution, as it would even work in corner cases like building 32-bit modules on 64-bit Windows. > Many thanks for the feedback. Might this be a candidate for inclusion > in libwin32 (or whatever that's become)? libwin32 doesn't exist anymore as a distribution; all modules are individually packaged on CPAN now. We do have a lib...@pe... mailing list, and the http://libwin32.googlecode.com repository though. The Win32API::File and Win32API::Registry modules are maintained elsewhere though, and Win32::API (which was not part of libwin32 before) is now included in the libwin32 project. You are welcome to add your Win32::VisualStyles module to the project as well; just send me a Google recognized email address (Gmail, Gtalk, Google docs etc) and I'll add you to the project to give you write access to the subversion repository. Cheers, -Jan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X