PBM_SETMARQUEE in VB6

[Deanna Earley]

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

[Farnsworth]

Post by Deanna Earley
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

Post by Deanna Earley
End Sub
Private Sub Timer1_Timer()
SendMessage ProgressBar1.hWnd, PBM_STEPIT, 0, ByVal 0&
End Sub

[Deanna Earley]

Post by Farnsworth

Post by Deanna Earley
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.
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.

[MikeD]

Post by Deanna Earley

Post by Farnsworth

Post by Deanna Earley
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.
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

[Deanna Earley]

Post by MikeD

Post by Deanna Earley

Post by Farnsworth

Post by Deanna Earley
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.
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.

[MikeD]

Post by Deanna Earley

Post by MikeD

Post by Deanna Earley
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. :)

Post by Deanna Earley
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.

Post by Deanna Earley
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

[Deanna Earley]

Post by Deanna Earley
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.
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.

[John K.Eason]

*Date:* Tue, 10 Dec 2013 09:22:43 +0000

Post by Deanna Earley
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.
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 (***@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[Deanna Earley]

Post by John K.Eason
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)

Post by John K.Eason
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.

[John K.Eason]

*Date:* Mon, 16 Dec 2013 10:33:33 +0000

Post by John K.Eason
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)

Post by John K.Eason
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 (***@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[Deanna Earley]

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.

[John K.Eason]

Post by Deanna Earley
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 (***@jeasonNoSpam.cix.co.uk) Remove the obvious to reply...

[Auric__]

Post by John K.Eason

Post by Deanna Earley
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.

Post by John K.Eason
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.

[Mayayana]

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

[Deanna Earley]

Post by Mayayana
| > 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.

Post by Mayayana
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.

[Mayayana]

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

[Deanna Earley]

Post by Mayayana
| 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.

Post by Mayayana
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?

Post by Mayayana
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)

[Mayayana]

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

[GS]

Post by Mayayana
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

[Arne Saknussemm]

Post by Deanna Earley
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

[Arne Saknussemm]

Post by Arne Saknussemm

Post by Deanna Earley
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

I was referring to

http://www.vbaccelerator.com/home/VB/Code/Libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp

[Deanna Earley]

Post by Arne Saknussemm

Post by Arne Saknussemm

Post by Deanna Earley
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

I was referring to
http://www.vbaccelerator.com/home/VB/Code/Libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp

Yes, the manifest is applied and InitCommonControls has been called. I
can see that is is using the v6/themed common controls.

[Arne Saknussemm]

Post by Deanna Earley

Post by Arne Saknussemm
I was referring to
http://www.vbaccelerator.com/home/VB/Code/Libraries/XP_Visual_Styles/Using_XP_Visual_Styles_in_VB/article.asp

Yes, the manifest is applied and InitCommonControls has been called.
I can see that is is using the v6/themed common controls.

ok, sorry for the dumb note, I was just trying to help.

As for the setmarquee, the PBS_SMOOTH and PBS_MARQUEE styles can't
co-exist, so you'll need to remove the "smooth" (which should be
the default style) bits and add the "marquee" ones

http://msdn.microsoft.com/en-us/library/bb760820%28VS.85%29.aspx

also, checking the documentation

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

it sounds like the default animation interval is 30 milliseconds; you
may try increasing the interval a bit (e.g. set it to 100) to see if it
has any effect

[MikeD]

Post by Deanna Earley
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.
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"?

OK. Did you actually *start* the timer? The below code worked fine for me,
and this was within the IDE (with a VB6.exe.manifest file). Note that I
explicitly declared constants As Long and passed 0& for lParam in the
SendMessage calls (because I believe it's "best practice" to do so). To be
fair, I DID test without the constants being declared As Long and passing 0
for lParam, and it did still work. Only other thing I can think of is that
perhaps the timer's interval needs to match the interval set with
PBM_SETMARQUEE. I didn't play around with other values to see if it'd make
a difference. Also, per the docs on MSDN, the return value for
PBM_SETMARQUEE is always True (i.e. 1) so that's useless. I DID try this
same code as is but WITHOUT setting the style or sending PBM_SETMARQUEE. The
progress bar still advanced from the PBM_STEPIT message, but in the normal
fashion rather than the marquee.

What I can deduce from this is that PBM_SETMARQUEE merely sets the mode (and
is what the docs say). It doesn't actually "advance" or animate the progress
though.

-----------------------------------------------------------------
Option Explicit

Private Const GWL_STYLE As Long = (-16)
Private Const PBS_MARQUEE As Long = &H8
Private Const WM_USER As Long = &H400
Private Const PBM_STEPIT As Long = WM_USER + 5
Private Const PBM_SETMARQUEE As Long = 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 Declare Sub InitCommonControls Lib "comctl32" ()

Private Sub Form_Initialize()

InitCommonControls

End Sub

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&

Timer1.Interval = 30
Timer1.Enabled = True

End Sub

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)

Timer1.Enabled = False

End Sub

Private Sub Timer1_Timer()

SendMessage ProgressBar1.hWnd, PBM_STEPIT, 0, ByVal 0&

End Sub
-----------------------------------------------------------------

Mike

[Deanna Earley]

Post by MikeD

Post by Deanna Earley
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"?

OK. Did you actually *start* the timer? The below code worked fine for
me, and this was within the IDE (with a VB6.exe.manifest file).

You misunderstand, the timer method works. My problem was with the
PBM_SETMARQUEE message that runs a timer internally in the progress bar
window/control.

I am using the extra timer as a workaround for now.

Post by MikeD
What I can deduce from this is that PBM_SETMARQUEE merely sets the mode
(and is what the docs say). It doesn't actually "advance" or animate the
progress though.

At least you're seeing the same as me.

Post by MikeD
Send the PBM_SETMARQUEE message to start or stop the animation.

This is also confirmed by the Control Spy tool from Microsoft which
animates as expected.
Loading Image...

[David Youngblood]

Post by Deanna Earley

Post by MikeD

Post by Deanna Earley
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"?

OK. Did you actually *start* the timer? The below code worked fine for
me, and this was within the IDE (with a VB6.exe.manifest file).

You misunderstand, the timer method works. My problem was with the
PBM_SETMARQUEE message that runs a timer internally in the progress bar
window/control.
I am using the extra timer as a workaround for now.

I tested your code on XP (without the timer) and it works as documented. I
can change the interval via the last parameter. Only when I move the
compiled app to Win7 it fails to animate. Your workaround may be your only
alternative, but you may want to restrict it the later OS's as including the
timer on XP doubles the speed.

David

[Deanna Earley]

Post by David Youngblood

Post by Deanna Earley

Post by MikeD

Post by Deanna Earley
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"?

OK. Did you actually *start* the timer? The below code worked fine for
me, and this was within the IDE (with a VB6.exe.manifest file).

You misunderstand, the timer method works. My problem was with the
PBM_SETMARQUEE message that runs a timer internally in the progress bar
window/control.
I am using the extra timer as a workaround for now.

I tested your code on XP (without the timer) and it works as documented. I
can change the interval via the last parameter. Only when I move the
compiled app to Win7 it fails to animate.

Interesting, thanks for that.

Post by David Youngblood
Your workaround may be your only alternative, but you may want to
restrict it the later OS's as including the timer on XP doubles the
speed.

I've removed the call to PBM_SETMARQUEE in favour of an external timer
for now so should run at "normal" speed.

[MikeD]

Post by MikeD
Send the PBM_SETMARQUEE message to start or stop the animation.

They do appear to suggest this, but it doesn't seem to be the case. In any
case, the work-around is pretty simple.

Just for grins and giggles, perhaps try creating the PB purely from API
(IOW, CreateWindowEx). That might at least confirm if it's the
implementation of the PB within the Windows Common Controls OCX.

I played around with it just a little bit more, and noted these things.

1. Simply setting the style and regularly sending PBM_STEPIT also works
(i.e. not actually ever sending PBM_SETMARQUEE).
2. MSDN says PBM_SETMARQUEE's lParam is a UINT (unsigned integer). Since
VB6 doesn't actually have unsigned data types, maybe that's the problem.
That's just a WAG.


Mike