perl-win32-gui-users Mailing List for Win32::GUI

Hi,
I wish to fully disable scrollbars in a Win32::GUI::Grid.
Even with AddGrid() options -hscroll=>0 and -vscroll=>0, scrollbars appear whenever the "virtual" spreadsheet is larger than the Grid's "viewing" area.
- Does an option exist to banish scrollbars forever?
- If not, can someone point me to build/install instructions for my modified GridCtrl source? I've bought Microsoft Visual C++ 6.0 (thanks, ebay), and have successfully built DLLs and  "Inline C" sections, but I can't get past 
    c:\gridctrl\memdc.h(27) : error C2504: 'CDC' : base class undefined
and subsequent errors. (I think it'd meet my goal to insert
    return;
immediately after GridCtrl.cpp line 3021):
    3020: void CGridCtrl::EnableScrollBars(int nBar, BOOL bEnable /*=TRUE*/)
    3021: {
    3022:     if (bEnable)
    3023:     {
    3024:         if (!IsVisibleHScroll() && (nBar == SB_HORZ || nBar == SB_BOTH))
    3025:         {
    3026:             m_nBarState |= GVL_HORZ;
    3027:             CWnd::EnableScrollBarCtrl(SB_HORZ, bEnable);
    3028:         }
    3029:         
    3030:         if (!IsVisibleVScroll() && (nBar == SB_VERT || nBar == SB_BOTH))
    3031:         {
    3032:             m_nBarState |= GVL_VERT;
    3033:             CWnd::EnableScrollBarCtrl(SB_VERT, bEnable);
    3034:         }
    3035:     }
    3036:     else
    3037:     {
    3038:         if ( IsVisibleHScroll() && (nBar == SB_HORZ || nBar == SB_BOTH))
    3039:         {
    3040:             m_nBarState &= ~GVL_HORZ; 
    3041:             CWnd::EnableScrollBarCtrl(SB_HORZ, bEnable);
    3042:         }
    3043:         
    3044:         if ( IsVisibleVScroll() && (nBar == SB_VERT || nBar == SB_BOTH))
    3045:         {
    3046:             m_nBarState &= ~GVL_VERT;
    3047:             CWnd::EnableScrollBarCtrl(SB_VERT, bEnable);
    3047:         }
    3049:     }
    3050: }
- Or is there a better approach?
(If I /can/ get this to build, is more "installation" involved than merely overwriting "c:/perl/site/lib/auto/Win32/GUI/Grid/Grid.dll"?)
- Or, can someone (only if easily and quickly) build and post a modified Grid.dll?
(FWIW, I've built test DLLs to identify the (four bytes or so) opcodes necessary to patch Grid.dll, but it's also getting time-consuming to find its GridCtrl.dll location.)
Thanks in advance,
Steven

Hi,
Not sure if I understand what you are wanting to do, but you can have a webserver (via HTTP::Daemon) running on one thread, while the main GUI is running in another. Each thread would block as you would expect: Win32::GUI until an event is fired and  HTTP::Daemon until a time out or HTTP request.
Is your problem in communicating between threads?
Cheers,
jez.

> Date: Tue, 28 Apr 2009 23:34:36 -0700
> From: rp...@ib...
> To: per...@li...
> Subject: [perl-win32-gui-users]  Using HTTP::Daemon within Win32::GUI
> 
> 
> Group;
> 
> I have an application i wrote to read data from various scanners (search
> socket scan). I currently use the keyboard to send the data to my target
> application ( a web page running in IE). This is now a problem because the
> data passed causes a few utilities used to control video drivers to freak
> out. 
> 
> My idea is to embed HTTP::Daemon in my application and use an AJAX call to
> see if any data is available. So my question is how bet to intergrate
> HTTP::Daemon with Thread utilities. my basic workflow will be:
> 
> 1) Main Application will get data from the scanner
> 2) Main Application will pass scanner data to child thread 
> 3) child thread waits until an AJAX call is placed and then returns the data
> 
> Am I barking up the wrong direction or what?
> 
> -- 
> View this message in context: http://www.nabble.com/Using-HTTP%3A%3ADaemon-within-Win32%3A%3AGUI-tp23291337p23291337.html
> Sent from the perl-win32-gui-users mailing list archive at Nabble.com.
> 
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/

_________________________________________________________________
Share your photos with Windows Live Photos – Free.
http://clk.atdmt.com/UKM/go/134665338/direct/01/

Group;

I have an application i wrote to read data from various scanners (search
socket scan). I currently use the keyboard to send the data to my target
application ( a web page running in IE). This is now a problem because the
data passed causes a few utilities used to control video drivers to freak
out. 

My idea is to embed HTTP::Daemon in my application and use an AJAX call to
see if any data is available. So my question is how bet to intergrate
HTTP::Daemon with Thread utilities. my basic workflow will be:

1) Main Application will get data from the scanner
2) Main Application will pass scanner data to child thread 
3) child thread waits until an AJAX call is placed and then returns the data

Am I barking up the wrong direction or what?

-- 
View this message in context: http://www.nabble.com/Using-HTTP%3A%3ADaemon-within-Win32%3A%3AGUI-tp23291337p23291337.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.

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

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.

> 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/

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

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.

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/

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

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> 

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/

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

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



 

Hi, there is an error talking about an undefined subroutine at line 623 of gb
file, if you try to save, i've fix it.
The error was: $file = GUI::GetOpenFileName [...], instead of
Win32::GUI::GetOpenFileName.
Regards

-- 
View this message in context: http://www.nabble.com/GUI-Builder-%28gb109%29-tp15762632p23100882.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.

Hi, there is an error talking about an undefined subroutine at line 623, if
you try to save, i've fix it.
The error was: $file = GUI::GetOpenFileName [...], instead of
Win32::GUI::GetOpenFileName.
-- 
View this message in context: http://www.nabble.com/GUI-Builder-%28gb109%29-tp15762632p23100783.html
Sent from the perl-win32-gui-users mailing list archive at Nabble.com.