Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #1897 > unrolled thread

PBM_SETMARQUEE in VB6

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-09 17:32 +0000
    Re: PBM_SETMARQUEE in VB6 "Farnsworth" <nospam@nospam.com> - 2013-12-09 14:37 -0500
      Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 08:54 +0000
        Re: PBM_SETMARQUEE in VB6 "MikeD" <nobody@nowhere.edu> - 2013-12-10 05:13 -0500
          Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 10:53 +0000
            Re: PBM_SETMARQUEE in VB6 "MikeD" <nobody@nowhere.edu> - 2013-12-10 06:05 -0500
    Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 09:22 +0000
      Re: PBM_SETMARQUEE in VB6 john@jeasonNoSpam.cix.co.uk (John K.Eason) - 2013-12-12 18:03 +0000
        Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-16 10:33 +0000
          Re: PBM_SETMARQUEE in VB6 john@jeasonNoSpam.cix.co.uk (John K.Eason) - 2013-12-16 18:59 +0000
            Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-17 09:04 +0000
              Re: PBM_SETMARQUEE in VB6 john@jeasonNoSpam.cix.co.uk (John K.Eason) - 2013-12-17 19:16 +0000
                Re: PBM_SETMARQUEE in VB6 "Auric__" <not.my.real@email.address> - 2013-12-18 05:52 +0000
                Re: PBM_SETMARQUEE in VB6 "Mayayana" <mayayana@invalid.nospam> - 2013-12-18 10:07 -0500
                  Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-18 16:22 +0000
                    Re: PBM_SETMARQUEE in VB6 "Mayayana" <mayayana@invalid.nospam> - 2013-12-18 13:52 -0500
                      Re: Windows version numbers (was: PBM_SETMARQUEE in VB6) Deanna Earley <dee.earley@icode.co.uk> - 2013-12-19 08:57 +0000
                        Re: Windows version numbers (was: PBM_SETMARQUEE in VB6) "Mayayana" <mayayana@invalid.nospam> - 2013-12-19 09:58 -0500
                  Re: PBM_SETMARQUEE in VB6 GS <gs@somewhere.net> - 2013-12-18 12:10 -0500
    Re: PBM_SETMARQUEE in VB6 Arne Saknussemm <motz001.20.wannabet@spamgourmet.com> - 2013-12-10 11:31 +0100
      Re: PBM_SETMARQUEE in VB6 Arne Saknussemm <motz001.20.wannabet@spamgourmet.com> - 2013-12-10 11:32 +0100
        Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 10:55 +0000
          Re: PBM_SETMARQUEE in VB6 Arne Saknussemm <motz001.20.wannabet@spamgourmet.com> - 2013-12-10 12:30 +0100
    Re: PBM_SETMARQUEE in VB6 "MikeD" <nobody@nowhere.edu> - 2013-12-10 06:00 -0500
      Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 11:37 +0000
        Re: PBM_SETMARQUEE in VB6 "David Youngblood" <dwy@flash.net> - 2013-12-10 06:02 -0600
          Re: PBM_SETMARQUEE in VB6 Deanna Earley <dee.earley@icode.co.uk> - 2013-12-10 12:28 +0000
        Re: PBM_SETMARQUEE in VB6 "MikeD" <nobody@nowhere.edu> - 2013-12-10 07:44 -0500

Page 1 of 2  [1] 2  Next page →

#1897 — PBM_SETMARQUEE in VB6

Hi all.

I've just tried setting up a scrolling marquee progress bar in one of my 
applications, and while it seems to switch into marquee mode, the 
automatic timer (set via PBM_SETMARQUEE) either fails or is ignored.

I have an appropriate visual style manifest.
I have called InitCommonControls in the form's Initialize event.
I am using the v5 SP2 common controls.
The project is compiled.
I have set the PBS_MARQUEE style and confirmed it has applied.
The PBM_SETMARQUEE message returns 1.

If I minimise and restore the window it progresses.
If I set .Value it progresses.
If I send PBM_STEPIT it progresses.
If I send PBM_SETMARQUEE it sits there doing nothing.

This is the same issue discussed here:
http://www.vbforums.com/showthread.php?462116-Marquee-Progressbar

Does anyone have any deeper insight as to why the VB wrapper is dropping 
the PBM_SETMARQUEE message or the associated timer events and why I need 
to do it "manually"?

Thanks

Here's the sample code I was using to test:
=====================================
Option Explicit

Private Const GWL_STYLE = (-16)
Private Const PBS_MARQUEE = &H8
Private Const WM_USER = &H400
Private Const PBM_STEPIT = WM_USER + 5
Private Const PBM_SETMARQUEE = WM_USER + 10

Private Declare Function GetWindowLong Lib "user32" Alias 
"GetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long) As Long
Private Declare Function SetWindowLong Lib "user32" Alias 
"SetWindowLongA" (ByVal hWnd As Long, ByVal nIndex As Long, ByVal 
dwNewLong As Long) As Long
Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" 
(ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As 
Any) As Long

Private Sub Form_Load()
   Dim Style As Long
   Style = GetWindowLong(ProgressBar1.hWnd, GWL_STYLE)
   Style = Style Or PBS_MARQUEE
   SetWindowLong ProgressBar1.hWnd, GWL_STYLE, Style
   SendMessage ProgressBar1.hWnd, PBM_SETMARQUEE, 1, ByVal 0
End Sub

Private Sub Timer1_Timer()
   SendMessage ProgressBar1.hWnd, PBM_STEPIT, 0, ByVal 0&
End Sub

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [next] | [standalone]

#1898

"Deanna Earley" <dee.earley@icode.co.uk> wrote in message 
news:l84urt$67g$1@speranza.aioe.org...
> Private Sub Form_Load()
>   Dim Style As Long
>   Style = GetWindowLong(ProgressBar1.hWnd, GWL_STYLE)
>   Style = Style Or PBS_MARQUEE
>   SetWindowLong ProgressBar1.hWnd, GWL_STYLE, Style
>   SendMessage ProgressBar1.hWnd, PBM_SETMARQUEE, 1, ByVal 0

I haven't tried your code, but you are passing 16-Bit Integer in the last 
parameter in the line above, which controls the update interval. You need to 
add "&" to it.

PBM_SETMARQUEE message:
http://msdn.microsoft.com/en-us/library/windows/desktop/bb760842%28v=vs.85%29.aspx

> End Sub
>
> Private Sub Timer1_Timer()
>   SendMessage ProgressBar1.hWnd, PBM_STEPIT, 0, ByVal 0&
> End Sub

[toc] | [prev] | [next] | [standalone]

#1900

On 09/12/2013 19:37, Farnsworth wrote:
> "Deanna Earley" <dee.earley@icode.co.uk> wrote in message
> news:l84urt$67g$1@speranza.aioe.org...
>> Private Sub Form_Load()
>>    Dim Style As Long
>>    Style = GetWindowLong(ProgressBar1.hWnd, GWL_STYLE)
>>    Style = Style Or PBS_MARQUEE
>>    SetWindowLong ProgressBar1.hWnd, GWL_STYLE, Style
>>    SendMessage ProgressBar1.hWnd, PBM_SETMARQUEE, 1, ByVal 0
>
> I haven't tried your code, but you are passing 16-Bit Integer in the last
> parameter in the line above, which controls the update interval. You need to
> add "&" to it.
>
> PBM_SETMARQUEE message:
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb760842%28v=vs.85%29.aspx

That won't (and doesn't) have any effect as it's passed ByVal and 
converted to a long anyway.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1902

"Deanna Earley" <dee.earley@icode.co.uk> wrote in message 
news:l86kse$iv3$1@speranza.aioe.org...
> On 09/12/2013 19:37, Farnsworth wrote:
>> "Deanna Earley" <dee.earley@icode.co.uk> wrote in message
>> news:l84urt$67g$1@speranza.aioe.org...
>>> Private Sub Form_Load()
>>>    Dim Style As Long
>>>    Style = GetWindowLong(ProgressBar1.hWnd, GWL_STYLE)
>>>    Style = Style Or PBS_MARQUEE
>>>    SetWindowLong ProgressBar1.hWnd, GWL_STYLE, Style
>>>    SendMessage ProgressBar1.hWnd, PBM_SETMARQUEE, 1, ByVal 0
>>
>> I haven't tried your code, but you are passing 16-Bit Integer in the last
>> parameter in the line above, which controls the update interval. You need 
>> to
>> add "&" to it.
>>
>> PBM_SETMARQUEE message:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb760842%28v=vs.85%29.aspx
>
> That won't (and doesn't) have any effect as it's passed ByVal and 
> converted to a long anyway.

Did you try that suggestion? It was my first thought as well. It's NOT being 
converted to a Long because the parameter definition is "As Any".

Mike
 

[toc] | [prev] | [next] | [standalone]

#1905

On 10/12/2013 10:13, MikeD wrote:
>
>
> "Deanna Earley" <dee.earley@icode.co.uk> wrote in message
> news:l86kse$iv3$1@speranza.aioe.org...
>> On 09/12/2013 19:37, Farnsworth wrote:
>>> "Deanna Earley" <dee.earley@icode.co.uk> wrote in message
>>> news:l84urt$67g$1@speranza.aioe.org...
>>>> Private Sub Form_Load()
>>>>    Dim Style As Long
>>>>    Style = GetWindowLong(ProgressBar1.hWnd, GWL_STYLE)
>>>>    Style = Style Or PBS_MARQUEE
>>>>    SetWindowLong ProgressBar1.hWnd, GWL_STYLE, Style
>>>>    SendMessage ProgressBar1.hWnd, PBM_SETMARQUEE, 1, ByVal 0
>>>
>>> I haven't tried your code, but you are passing 16-Bit Integer in the
>>> last
>>> parameter in the line above, which controls the update interval. You
>>> need to
>>> add "&" to it.
>>>
>>> PBM_SETMARQUEE message:
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb760842%28v=vs.85%29.aspx
>>>
>>
>> That won't (and doesn't) have any effect as it's passed ByVal and
>> converted to a long anyway.
>
> Did you try that suggestion? It was my first thought as well. It's NOT
> being converted to a Long because the parameter definition is "As Any".

I did (hence the "and doesn't" :).
It is "As Any" but passing ByVal means it's converted to a Long instead 
of pointer to X implied by ByRef/As Any.
It also failed with an alternative "ByVal lParam As Long" declaration.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1908

"Deanna Earley" <dee.earley@icode.co.uk> wrote in message 
news:l86rqr$594$1@speranza.aioe.org...
>>>
>>> That won't (and doesn't) have any effect as it's passed ByVal and
>>> converted to a long anyway.
>>
>> Did you try that suggestion? It was my first thought as well. It's NOT
>> being converted to a Long because the parameter definition is "As Any".
>
> I did (hence the "and doesn't" :).

I did figure that's what you meant, but wanted to be sure, so I asked. :)


> It is "As Any" but passing ByVal means it's converted to a Long instead of 
> pointer to X implied by ByRef/As Any.

No, I think you're wrong there.  Simply passing ByVal does not implicitly 
convert an integer to a long.

> It also failed with an alternative "ByVal lParam As Long" declaration.

That would have ensured it was a Long, but as I mentioned in my other reply, 
that didn't appear to be the problem anyway.

Mike
 

[toc] | [prev] | [next] | [standalone]

#1901

On 09/12/2013 17:32, Deanna Earley wrote:
> Hi all.
>
> I've just tried setting up a scrolling marquee progress bar in one of my
> applications, and while it seems to switch into marquee mode, the
> automatic timer (set via PBM_SETMARQUEE) either fails or is ignored.
>
> I have an appropriate visual style manifest.
> I have called InitCommonControls in the form's Initialize event.
> I am using the v5 SP2 common controls.
> The project is compiled.
> I have set the PBS_MARQUEE style and confirmed it has applied.
> The PBM_SETMARQUEE message returns 1.
>
> If I minimise and restore the window it progresses.
> If I set .Value it progresses.
> If I send PBM_STEPIT it progresses.
> If I send PBM_SETMARQUEE it sits there doing nothing.
>
> This is the same issue discussed here:
> http://www.vbforums.com/showthread.php?462116-Marquee-Progressbar
>
> Does anyone have any deeper insight as to why the VB wrapper is dropping
> the PBM_SETMARQUEE message or the associated timer events and why I need
> to do it "manually"?

Note that the PBM_SETMARQUEE message is being processed correctly as 
without it it won't progress when redrawn (on minimise/restore).
This suggest that it's just the timer message that's being dropped.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1914

In article <l86mh1$nbq$1@speranza.aioe.org>, dee.earley@icode.co.uk (Deanna Earley)
wrote:

> *From:* Deanna Earley <dee.earley@icode.co.uk>
> *Date:* Tue, 10 Dec 2013 09:22:43 +0000
> 
> On 09/12/2013 17:32, Deanna Earley wrote:
> > Hi all.
> >
> > I've just tried setting up a scrolling marquee progress bar in 
> > one of my
> > applications, and while it seems to switch into marquee mode, the
> > automatic timer (set via PBM_SETMARQUEE) either fails or is 
> > ignored.
> >
> > I have an appropriate visual style manifest.
> > I have called InitCommonControls in the form's Initialize event.
> > I am using the v5 SP2 common controls.
> > The project is compiled.
> > I have set the PBS_MARQUEE style and confirmed it has applied.
> > The PBM_SETMARQUEE message returns 1.
> >
> > If I minimise and restore the window it progresses.
> > If I set .Value it progresses.
> > If I send PBM_STEPIT it progresses.
> > If I send PBM_SETMARQUEE it sits there doing nothing.
> >
> > This is the same issue discussed here:
> > http://www.vbforums.com/showthread.php?462116-Marquee-Progressbar
> >
> > Does anyone have any deeper insight as to why the VB wrapper is 
> > dropping
> > the PBM_SETMARQUEE message or the associated timer events and why 
> > I need
> > to do it "manually"?
> 
> Note that the PBM_SETMARQUEE message is being processed correctly 
> as without it it won't progress when redrawn (on minimise/restore).
> This suggest that it's just the timer message that's being dropped.

 Out of interest, what interval do you have set in Timer1?
I've just stuck the code from your initial posting on to a form with a timer and
progressbar on it. I'm running under XP in Classic view, so haven't bothered with a
manifest.
If I set the Timer1 interval to 1(!), the marquee does work here, but it's at a
rate of about one sector every two seconds! Set it to 100 and it's so slow that
you'd be forgiven for thinking that it wasn't working at all. It works exactly the
same whether you're using the VB5 control (Comctl32.ocx) or VB6 (MsComctl.ocx) one.
 Can't really offer any explanation on what's causing it though, I'm afraid.

Regards
       John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[toc] | [prev] | [next] | [standalone]

#1915

>   Out of interest, what interval do you have set in Timer1?

I was using 30 which is the default PBM_SETMARQUEE interval (if you pass 0)

> I've just stuck the code from your initial posting on to a form with a timer and
> progressbar on it. I'm running under XP in Classic view, so haven't bothered with a
> manifest.
> If I set the Timer1 interval to 1(!), the marquee does work here, but it's at a
> rate of about one sector every two seconds! Set it to 100 and it's so slow that
> you'd be forgiven for thinking that it wasn't working at all.

Then it's not in marquee mode.
This is most likely as it's not compiled, and so not getting the correct 
version of the controls.
Using ComCtl32.ocx, a manifest, and compiling should get the correct style.

While my problem is that it's in marquee mode fine, other posts imply 
that it's an OS issue. On Windows XP the internal timer works fine, on 
Windows 7 it doesn't.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1916

In article <l8mktq$c1b$1@speranza.aioe.org>, dee.earley@icode.co.uk (Deanna Earley)
wrote:

> *From:* Deanna Earley <dee.earley@icode.co.uk>
> *Date:* Mon, 16 Dec 2013 10:33:33 +0000
> 
> >   Out of interest, what interval do you have set in Timer1?
> 
> I was using 30 which is the default PBM_SETMARQUEE interval (if you 
> pass 0)
> 
> > I've just stuck the code from your initial posting on to a form 
> > with a timer and
> > progressbar on it. I'm running under XP in Classic view, so 
> > haven't bothered with a
> > manifest.
> > If I set the Timer1 interval to 1(!), the marquee does work here, 
> > but it's at a
> > rate of about one sector every two seconds! Set it to 100 and 
> > it's so slow that
> > you'd be forgiven for thinking that it wasn't working at all.
> 
> Then it's not in marquee mode.
> This is most likely as it's not compiled, and so not getting the 
> correct version of the controls.
> Using ComCtl32.ocx, a manifest, and compiling should get the 
> correct style.
> 
> While my problem is that it's in marquee mode fine, other posts 
> imply that it's an OS issue. On Windows XP the internal timer works 
> fine, on Windows 7 it doesn't.

Fair enough. I just tried it out of interest to see what happened because it would
be handy to have in one of my own programs, but it's not worth fiddling around with
manifests if it's purely for my own use.

Regards
       John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[toc] | [prev] | [next] | [standalone]

#1917

On 16/12/2013 18:59, John K.Eason wrote:
> It's not worth fiddling around with manifests if it's purely for my
> own use.

You really should be adding manifests (for visual styles, elevation and 
supported windows version) to any current application you release.
Of course for private applications installed on 1/2 of your own (maybe 
older) machines it's normally fine.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1918

In article <l8p43p$mnj$1@speranza.aioe.org>, dee.earley@icode.co.uk (Deanna Earley)
wrote:

> You really should be adding manifests (for visual styles, elevation 
> and supported windows version) to any current application you 
> release.
> Of course for private applications installed on 1/2 of your own 
> (maybe older) machines it's normally fine.

*All* the programs I write are purely for my own use (I'm a long-retired hobby
tinkerer), so in my case it doesn't really matter, especially as all my PCs (XP,
Vista and W7) are set to Classic view and look visually as close to Windows 95 as I
can get them! :^))

Regards
       John (john@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[toc] | [prev] | [next] | [standalone]

#1919

John K.Eason wrote:

> In article <l8p43p$mnj$1@speranza.aioe.org>, dee.earley@icode.co.uk
> (Deanna Earley) wrote:
>
>> You really should be adding manifests (for visual styles, elevation
>> and supported windows version) to any current application you
>> release.
>> Of course for private applications installed on 1/2 of your own
>> (maybe older) machines it's normally fine.
>
> *All* the programs I write are purely for my own use (I'm a long-retired
> hobby tinkerer), so in my case it doesn't really matter,

Amen to that.

> especially as all my PCs (XP, Vista and W7) are set to Classic view and
> look visually as close to Windows 95 as I can get them! :^))

...not so much to that.

-- 
Now I see how an intergalactic war started...
It's the Iraqi war I can't figure out.

[toc] | [prev] | [next] | [standalone]

#1922

| > You really should be adding manifests (for visual styles, elevation
| > and supported windows version) to any current application you
| > release.
| > Of course for private applications installed on 1/2 of your own
| > (maybe older) machines it's normally fine.
|
| *All* the programs I write are purely for my own use (I'm a long-retired 
hobby
| tinkerer), so in my case it doesn't really matter, especially as all my 
PCs (XP,
| Vista and W7) are set to Classic view and look visually as close to 
Windows 95 as I
| can get them! :^))

  I distribute as freeware/shareware and have never bothered
with manifests. Perhaps it's noticeable to some people, but
what I see is a standard VB window wrapped with Microsoft's
GUI techno-kitsch-du-jour chrome. It seems fine. Standardization is
not what it used to be, anyway. Increasingly, common software
has its own GUI scheme. I've actually been doing that myself
for more "civilian-oriented" software. One can use frameless
windows, then use API to provide drag handles. Along with
custom buttons, it becomes a new GUI. I do it not so much
because a VB window doesn't look good on Win7, but because
VB windows have never looked very good, and it shows more
on Win7.

 (That's one thing -- perhaps the only thing -- I like
about .Net. The first time I ever tried using a .Net program
(I had to because my neice had written for a school class)
I was impressed with the look of "fine finish" that the basic
GUI had. It was like booting into Linux. Everything graphical
was just a bit finer than regular Windows, which is a bit finer
than VB.)

   I think it's interesting and telling that the current bandwagon
craze is anti-skeuomorphic. That's been coming for awhile, with
the simplifying of buttons and the odd non-color off-white putty
that Win7 has in windows. The Metro screen is a bit different,
being simple due to touch design as well as limited options. (I
imagine that in a few years today's Metro might be mistaken for
a McDonalds tablet menu.... Touch fries, Big Mac and Coke for
20% off.) But Metro also conspicuously lacks graphical detail.
That's a sign that computer graphics have come of age. When
the limits are reached, simplicity becomes the object of worship.

  (As, for example, by the 60s and 70s people could have any
wall paint color they liked, including fluorescent colors. Previously
a more limited palette was available. But once one could have
rich plum it was no longer a special color. Thus 80s yuppies
fretted over choosing between three different hues of "off-white
dustbunnie".)

   The obsession these days is simplicity not only with graphics
but with interfaces altogether. Last week I needed to turn on
a Mac all-in-one and couldn't find any buttons at all. It turned
out a button was hidden on the back of the left side. The
AppleSeeds think that's very "cool" -- a slick slab of ultimate
tech. But it's really no different from the 3-D block letters of
early webpages: Apple is trying to be "futuristically clever". The
obvious problem with that is that their device needs buttons.
Removing them is simply a design flaw in the service of fantasy.
Probably Steve Jobs would like the thing to turn on automatically
when one enters the room, but again, that's really a stupid idea
once one gets over the wow factor.

   So, what's the moral here? I'm not sure. Like you, I always set
Classic view on all PCs. I don't want the GUI to be an event. I
want it to be functional. Though I have made a few adjustments
in the interest of civility.... My "recycle bin" is named "Rubbish"
and is made of red oak rather than transluscent Ikea plastic. 

[toc] | [prev] | [next] | [standalone]

#1923

On 18/12/2013 15:07, Mayayana wrote:
> | > You really should be adding manifests (for visual styles, elevation
> | > and supported windows version) to any current application you
> | > release.
> | > Of course for private applications installed on 1/2 of your own
> | > (maybe older) machines it's normally fine.
> |
> | *All* the programs I write are purely for my own use (I'm a long-retired
> | hobby tinkerer), so in my case it doesn't really matter, especially as
> | all my PCs (XP, Vista and W7) are set to Classic view and look visually
> | as close to Windows 95 as I can get them! :^))
>
>    I distribute as freeware/shareware and have never bothered
> with manifests. Perhaps it's noticeable to some people, but
> what I see is a standard VB window wrapped with Microsoft's
> GUI techno-kitsch-du-jour chrome. It seems fine.

That's not all a manifest is used for.
It's also used to switch off/disable all the compatibility hacks that 
newer versions of Windows have to implement for older applications.
This includes virtualisation so the users gets real errors when they try 
and save in stupid location, The lying version numbers (Windows 8.1+) 
various graphics, DirectX, and other API features.

> Standardization is not what it used to be, anyway. Increasingly,
> common software has its own GUI scheme.

Yes, I hate skinned applications. I want applications to look how I've 
configured my system to look, not the random colour scheme the developer 
thinks will look better.

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1926

| That's not all a manifest is used for.
| It's also used to switch off/disable all the compatibility hacks that
| newer versions of Windows have to implement for older applications.
| This includes virtualisation so the users gets real errors when they try
| and save in stupid location, The lying version numbers (Windows 8.1+)
| various graphics, DirectX, and other API features.
|

  I try to just make sure things work in Win7 without
a manifest or other extras. In the same way, I name
my installers with "setup" to get needed permission.
I know one is "supposed to" use a manifest, but the
file naming works and it's a lot easier.

  Lying version numbers is a new one to me, though.
The OS version number started "lying" in Vista and
I had to use an alternate OSV check that checks
available APIs and checks the version of shell32.dll.
That works. But what's the Win8.1 difference? 

[toc] | [prev] | [next] | [standalone]

#1927 — Re: Windows version numbers (was: PBM_SETMARQUEE in VB6)

On 18/12/2013 18:52, Mayayana wrote:
> | That's not all a manifest is used for.
> | It's also used to switch off/disable all the compatibility hacks that
> | newer versions of Windows have to implement for older applications.
> | This includes virtualisation so the users gets real errors when they try
> | and save in stupid location, The lying version numbers (Windows 8.1+)
> | various graphics, DirectX, and other API features.
> |
>
>    I try to just make sure things work in Win7 without
> a manifest or other extras. In the same way, I name
> my installers with "setup" to get needed permission.
> I know one is "supposed to" use a manifest, but the
> file naming works and it's a lot easier.

As a compatibility shim and may not be enabled on all machines.
Do you really want to rely on something "guessing" what you mean?
Why not be explicit, it's generally a good idea all round.

>    Lying version numbers is a new one to me, though.
> The OS version number started "lying" in Vista and

How did it start lying in Vista?

> I had to use an alternate OSV check that checks
> available APIs and checks the version of shell32.dll.
> That works. But what's the Win8.1 difference?

Windows 8.1 (6.3) reports that it is Windows 8 (6.2) unless your 
application explicitly says it knows about Windows 8.1 to fix 
applications that do screwy version checks and report unknown version as 
"Unsupported OS, please install a newer version" (As I said, 
compatibility hacks for shit developers)

-- 
Deanna Earley (dee.earley@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the 
group.)

[toc] | [prev] | [next] | [standalone]

#1928 — Re: Windows version numbers (was: PBM_SETMARQUEE in VB6)

| >    Lying version numbers is a new one to me, though.
| > The OS version number started "lying" in Vista and
|
| How did it start lying in Vista?
|

  There was a lot of discussion about this at the time:

http://www.thedelphigeek.com/2007/02/four-ways-to-detect-vista.html

  Compatibility mode causes a false return from GetVersionEx.
Compatibility mode simply is not. So I don't test for it. I try
to make sure things just work on all systems. When Vista
came out I had a lot of scripting DLLs I give away that were
likely to have functionality blocked by UAC. So I didn't want
them to be usable on Vista/7, at least until I could update
them. I didn't want the likely scenario where someone manages
to make it work but then writes to me to complain that it
doesn't work as expected. So I needed to get the real version
number at load and act accordingly. My final solution was to use
a custom function:

Public Function IsVista() As Boolean
  Dim LRet As Long, hLib As Long, LShl As Long, L2 As Long
  Dim OSV As OSVERSIONINFO
  Dim DVI As DLLVERSIONINFO
    IsVista = False
       On Error Resume Next

'--------------------- GetVersionEx ------------------
   OSV.dwOSVersionInfoSize = Len(OSV)
   LRet = GetVersionEx(OSV)
     If (OSV.dwPlatformId = 2) And (OSV.dwMajorVersion >= 6) Then
        IsVista = True
        Exit Function
     End If

 '------------- check for Vista-only API --------------------

  LRet = 0
  hLib = LoadLibrary("kernel32.dll")
    If (hLib <> 0) Then
       LRet = GetProcAddress(hLib, "GetLocaleInfoEx")
       L2 = FreeLibrary(hLib)
    End If
      If (LRet <> 0) Then
           IsVista = True
           Exit Function
       End If

 '----------------------- shell32 dllgetversion -----------

 LRet = 0
 hLib = LoadLibrary("shell32.dll")
   If (hLib <> 0) Then
     LRet = GetProcAddress(hLib, "DllGetVersion")
     L2 = FreeLibrary(hLib)
   End If
     If (LRet <> 0) Then
         DVI.cbSize = Len(DVI)
         LRet = DllGetVersion(DVI)
           If (LRet = 0) Then
              If (DVI.dwMajorVersion = 6) And (DVI.dwBuildNumber > 5000) 
Then
                IsVista = True
              End If
           End If
     End If

End Function

  I know that your response to that will probably be something
like, "compatibility mode is supposed to work that way". Maybe
so. But it's lying. And it doesn't allow me to be responsible for
my own software. It tells me I'm on XP but it doesn't emulate
XP. If someone uses my components to do something like write
to HKLM\Software or access files in the Program Files folder on
Vista/7 it's likely to fail, where it would have worked on XP. Then
I'm the one who gets the complaint. (Not to mention other
numerous details that could change between OS versions:
Display, shell, etc. I can't assume that compatibility mode is
going to substitute for me updating and testing.)

  And I really can't say I think it's unreasonable for someone to
think my software is at fault. They did take care to run in
"compatibility mode", after all. :) So it saves everyone trouble
if I just block DLLs that haven't been updated/tested on Vista/7.


| > I had to use an alternate OSV check that checks
| > available APIs and checks the version of shell32.dll.
| > That works. But what's the Win8.1 difference?
|
| Windows 8.1 (6.3) reports that it is Windows 8 (6.2) unless your
| application explicitly says it knows about Windows 8.1 to fix
| applications that do screwy version checks and report unknown version as
| "Unsupported OS, please install a newer version" (As I said,
| compatibility hacks for shit developers)
|
    Interesting. I'm afraid I'm behind the times. At this
point I'm testing on Win7 and defining that as "should
also work fine on Win8, since that's basically the same
thing with TileCity plastered onto the Desktop".

With Microsoft so doggedly determined to convert Windows
into a locked-down services interface, I'm seriously
wondering whether I'll ever really use anything beyond Win7.
Businesses have been avoiding Win8, anyway. The way it
looks to me is that one of two things will probably happen:

1) Microsoft doesn't give up. Win9 is basically RT. Business
switches to Linux and/or cloud. The era of the Windows desktop
ends.

2) Microsoft worries, recognizing that Windows and Office are
the only products they have that anyone wants in the first place.
They then reluctantly give up on trying to create a paid services
empire, Win9 arrives as a reasonably usable OS, and Win8/8.1
becomes redefined as the biggest lemon MS ever came out
with. (MS themselves, of course, will lead the way in disowning
their own children, just as they have with ME and Vista. They're
the only company I know that succeeds with a marketing
strategy of, "You should buy our latest product, because the
last one we sold you was real junk.")

  In the current air of tablet mania, possibility #2 probably
seems farfetched to most people. It may be. On the other
hand, a world of locked-down tablets and spyware web
services is also a bit farfetched, especially for business.
Either way, I know I won't be writing trinkets for tablets
that have to be approved by MS. So if Win9 isn't a turnaround
I see no reason to wade into the sleazy muck of Metro. 

[toc] | [prev] | [next] | [standalone]

#1925

> I do it not so much
> because a VB window doesn't look good on Win7, but because
> VB windows have never looked very good, and it shows more
> on Win7.

My VB windows look the same on Win7 (HP/Pro) as they do in XP! Mind 
you, I use 'Classic' view...

-- 
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
  comp.lang.basic.visual.misc
  microsoft.public.vb.general.discussion



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#1903

> I've just tried setting up a scrolling marquee progress bar in one of
> my applications, and while it seems to switch into marquee mode, the 
> automatic timer (set via PBM_SETMARQUEE) either fails or is ignored.

just picking it out of memory <g> ... doesn't VB need to send to
controls some message (or call some API) to tell them that we want to
use some kinda/sorta "enhanced style" ? Sorry to be obscure but I'm
"out of home" and I'm just trying to squeeze infos out of my poor brain

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web