Common Dialog Function

[Ivar]

Hi All

My lil App (VB6) wants to import Excel or csv files
Behind the Browse button is code based on AllAPI's GetOpenFileName
All Works Well. However!

Just can't get my head around making the windows common dialog list multiple
file types

Can anyone supply a function where the common show open dialog can list xls,
xlsx and csv files in it's names list.

Also:
More of a winders question than vb6 I suspect
All the common dialog boxes called by my lil app are maximized and are full
screen, even covers the task bar, This also applies to VB6 dialog boxes such
as Make Exe, Add New Form\Module\Class or save project As etc
All the controls are the same size as they used to be (With The VB6 dialog
boxes), but are all in the top left corner of the form. Not a big problem
but it does look strange.

I'm Assuming I upset something while trying to Do the first question. Any
Ideas on how to fix?

Thanks for reading

Ivar

[Mike Williams]

Post by Ivar
My lil App (VB6) wants to import Excel or csv files
Behind the Browse button is code based on AllAPI's
GetOpenFileName All Works Well. However!
Just can't get my head around making the windows _
common dialog list multiple file types
Can anyone supply a function where the common
show open dialog can list xls, xlsx and csv files in it's
names list.

You would normally use a short descriptive string followed by a Chr$(0)
followed by the desired file extensions each separated by a semicolon and
then a final Chr$(0), something like:

OFName.lpstrFilter = "Ivar Files (.xls .xlsx .csv)" & Chr$(0) &
"*.xls;*.xlsx;*.csv" & Chr$(0)

Post by Ivar
All the common dialog boxes called by my lil app are maximized and
are full screen, even covers the task bar, This also applies to VB6
dialog boxes such as Make Exe, Add New Form\Module\Class or
save project As etc All the controls are the same size as they used
to be (With The VB6 dialog boxes), but are all in the top left
corner of the form.

Not sure what you've done there. Does this apply only when you run your
program in the IDE and are the dialog boxes called by your app the correct
size when run as a compiled exe? Also, does this problem persist even after
you have restarted your machine?

Mike

[Deanna Earley]

Post by Ivar
Hi All
My lil App (VB6) wants to import Excel or csv files
Behind the Browse button is code based on AllAPI's GetOpenFileName
All Works Well. However!
Just can't get my head around making the windows common dialog list
multiple file types
Can anyone supply a function where the common show open dialog can list
xls, xlsx and csv files in it's names list.

Set the filter to something like:
CSV files (*.csv)|*.csv|Excel files (*.xls, *.xlsx)|*.xls;*.xlsx|All
files (*.*)|*.*

[Deanna Earley]

Post by Deanna Earley

Post by Ivar
Hi All
My lil App (VB6) wants to import Excel or csv files
Behind the Browse button is code based on AllAPI's GetOpenFileName
All Works Well. However!
Just can't get my head around making the windows common dialog list
multiple file types
Can anyone supply a function where the common show open dialog can list
xls, xlsx and csv files in it's names list.

CSV files (*.csv)|*.csv|Excel files (*.xls, *.xlsx)|*.xls;*.xlsx|All
files (*.*)|*.*

Sorry, my filter was based on the common control that my wrapper
converts. Try using null characters instead of the pipes and doubling
the null on the end.

[Mike Williams]

Post by Ivar
All the common dialog boxes called by my lil app are maximized
and are full screen, even covers the task bar, This also applies
to VB6 dialog boxes such as Make Exe . . .

I wonder if you have at some point included the OFN_ENABLESIZING flag,
perhaps inadvertently? This would allow the user (or you while testing) to
manually drag the dialog to a very large size? I don't think this would
affect the size of the VB IDE's own dialog's though.

Mike

[Bob Butler]

Post by Mike Williams

Post by Ivar
All the common dialog boxes called by my lil app are maximized
and are full screen, even covers the task bar, This also applies
to VB6 dialog boxes such as Make Exe . . .

I wonder if you have at some point included the OFN_ENABLESIZING flag,
perhaps inadvertently? This would allow the user (or you while testing) to
manually drag the dialog to a very large size? I don't think this would
affect the size of the VB IDE's own dialog's though.

I have the same issue with 1 app on a Vista box. When it opens the dialog
box it is maximized but double-clicking the dialog box title bar puts it
back to normal. Other apps using the same code do not exhibit the problem
and the same exe doesn't do it on other systems. I've searched the registry
and everywhere I can think of with no luck. I've learned to live with it.

[Mike Williams]

Post by Bob Butler
I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it before
but it seems that Windows remembers the most recent window state (and the
size) of file dialogs on a program by program basis and that the memory
persists between restarts, so it must be in the registry somewehere. I
haven't looked for it yet but I'm sure it must be there somewhere. Perhaps
the entry has become corrupt for the specific program you are talking about?

This "remember the previous file dialog window setting" applies to all
individual compiled VB6 programs on a program by program basis (and to
NotePad and MS Word etc, etc) but it will apply on an "IDE basis" to every
program that is run in the IDE. So the OP (Ivar) has probably just double
clicked a file dialog while it was open in the IDE (or on a file dialog of a
VB6 program running in the IDE) to make it maximized and this will be
remembered even through restarts. The result would be exactly what Ivar has
described (for example a maximized dialog when using the VB IDE File / Open
or File / Make Exe dialog, and the soluition of course is for Ivar to double
click any of those file dialogs once again to normalize it, and that
normalized setting should be remembers for the future. Actually, now that I
think about it, this sounds like pretty standard Windows stuff, and I'm sure
almost everybody knows it, but I must admit that it is something I have only
just noticed myself. If somebody really needs to then I'm sure it would be
possible to force any file dialog used in a compiled VB6 exe to open
normalised if it just happened to have been maximized by the user last time
he used that same program, but I'm not sure whether it would be a good idea
to bypass Windows normal behaviour in that way.

Mike

[Bob Butler]

Post by Mike Williams

Post by Bob Butler
I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it before
but it seems that Windows remembers the most recent window state (and the
size) of file dialogs on a program by program basis and that the memory
persists between restarts, so it must be in the registry somewehere. I
haven't looked for it yet but I'm sure it must be there somewhere. Perhaps
the entry has become corrupt for the specific program you are talking about?

That's been my assumption but I haven't found it yet. It's probably in some
binary value somewhere.

[ralph]

On Tue, 13 Mar 2012 20:31:35 -0000, "Mike Williams"

Post by Mike Williams

Post by Bob Butler
I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it before
but it seems that Windows remembers the most recent window state (and the
size) of file dialogs on a program by program basis and that the memory
persists between restarts, so it must be in the registry somewehere. I
haven't looked for it yet but I'm sure it must be there somewhere. Perhaps
the entry has become corrupt for the specific program you are talking about?

Finding that location can be an interesting adventure.

This information is saved as a Property Page. Controls and Devices
also have Property Pages.

Property Pages are saved in two main places - a Resource File (for
non-changeable), and the Registery for changeable. The latter has the
extra complication of a different saving if Application/Install or if
dynamic per-user/session. (Well, a third if you include ASP which
stores its Property Pages in folders.)

While there are some common, more or less, 'standard' locations in the
Registry for some items, for example Devices usually store them in ...
HKLM\System\CurrentControlSet\Control\Class\<GUID>
In practice you'll find them stuck almost anywhere. <g>

Exactly where depends on the developer and the tool used to create the
Property Page. Even Windows developers or major application developers
(Office, for example) are seldom consistent. Although the last time I
went searching there seemed to be more cohesion.

All Microsoft will say on the subject is ... "Property pages are
registered in the component category for the object that they are
designed to apply against." Huh?

Which pretty much sums it all up ... "Property Pages are stored
wherever you happen to find them." <bg>

I think that is why there is very little documention on where Property
Pages are stored. The exception list would exceed the rules by a
factor of several thousand.

Even if you do find the location, the information/data is stored as
binary. There is no standard format. Creating a Property Page and
adding properties in effect defines the 'structure'. So every Property
Page is essentially a new format.

Thus one is often faced with something like this ...
Property -> 12 34 28 6f 73 75 5c 69 45 4a 31 71 3d 7f 11 ...
Good luck with modifying that. <g>

hth
-ralph

[Deanna Earley]

Post by Mike Williams

I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it
before but it seems that Windows remembers the most recent window state
(and the size) of file dialogs on a program by program basis and that
the memory persists between restarts, so it must be in the registry
somewehere. I haven't looked for it yet but I'm sure it must be there
somewhere. Perhaps the entry has become corrupt for the specific program
you are talking about?

I quick process explorer trace shows the data to be stored as a fairly
simple binary blob under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU

When I close the dialog, it enumerates all entries until it find the
value matching the exe name (not the full path) then updates it.

It also updates various other locations with the folder view state
(icons size, sort, etc) and the nav pane expanded state but they may be
more generic shell settings.

[Mike Williams]

Post by Deanna Earley
process explorer trace shows the data to be stored
as a fairly simple binary blob under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU
When I close the dialog, it enumerates all entries until it
find the value matching the exe name (not the full path)
then updates it.

Now that's very interesting. I did know about the general behaviour, for
example the exe name (not full path) thing, because a couple of simple tests
confirmed it empirically, but I did not know where the information was
stored. I was certain it would be in the registry somewhere but I had not
actually looked for it. Thanks for that piece of information. It might be
interesting to now look at how the size and window state information is
encoded, which at least at first sight seems to be fairly straightforward.
Clearly the exe name is contained very simply in bytes 0000 to 0207 (the
name followed by a load of trailing zeros) and the data itself is contained
in bytes 0208 to 024F. The dialog window state (maximized or normal) is
represented by the last four bytes (0000 for normalized and FFFF for
maximized), a fact which can also be confirmed empirically, and it looks as
though the normalized size should be easy to figure out as well. There is
space for lots of other stuff of course, but I haven't looked into that yet.
Thanks for the info regarding the location. This should help Bob Butler to
pin down his own specific problem.

Mike

[Mike Williams]

. . . . The dialog window state (maximized or normal) is represented by
the last four bytes (0000 for normalized
and FFFF for maximized) . . .

Oops! I of course meant to say, 00000000 for normalized and FFFFFFFF for
maximized.

Mike

[Bob Butler]

Post by Deanna Earley

Post by Mike Williams

I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it
before but it seems that Windows remembers the most recent window state
(and the size) of file dialogs on a program by program basis and that
the memory persists between restarts, so it must be in the registry
somewehere. I haven't looked for it yet but I'm sure it must be there
somewhere. Perhaps the entry has become corrupt for the specific program
you are talking about?

I quick process explorer trace shows the data to be stored as a fairly
simple binary blob under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU

I've found that before and just checked again but haven't been able to fix
the problem by modifying those entries.

[Mike Williams]

I've found that before [the CIDSizeMRU key in
the Registry] and just checked again but haven't
been able to fix the problem by modifying those
entries.

Perhaps it has become corrupt in some way or contains duplicate entries or
something. Have you tried deleting the entire key, or at least its entire
contents, to see if that fixes the problem. I've just done that as a test on
my own Vista machine, but if you're not happy about deleting the entire key
or its contents on your own machine then you could simply rename it, to
CIDSizeMRUBackup for example, and allow Windows to create a new CIDSizeMRU
key and populate it with new entries as you use dialogs in various programs,
each of which should open normalised unless you manually change them. Does
that fix the problem with your errant program?

Mike

[Bob Butler]

Post by Mike Williams

I've found that before [the CIDSizeMRU key in
the Registry] and just checked again but haven't
been able to fix the problem by modifying those
entries.

Perhaps it has become corrupt in some way or contains duplicate entries or
something. Have you tried deleting the entire key, or at least its entire
contents, to see if that fixes the problem.

I deleted everything under
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32 and
rebooted. When I ran the app and used file/open it displayed full screen so
I cancelled and exited the app. The registry showed a new entry that ended
ffffffff so I edited it to all zeros and tried the app again; still full
screen. I double-clicked the title bar to get the standard size back and
selected a file and exited the app. The registry entry now ended in all
zeroes but when I restarted the app the dialog is still full screen.

Something else somewhere is doing this.

[Mike Williams]

Post by Bob Butler
I deleted everything under
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
and rebooted. When I ran the app and used file/open it displayed
full screen so I cancelled and exited the app. The registry showed
a new entry that ended ffffffff so I edited it to all zeros and tried the
app again; still full screen. I double-clicked the title bar to get the
standard size back and selected a file and exited the app. The
registry entry now ended in all zeroes but when I restarted the app
the dialog is still full screen. Something else somewhere is doing this.

It seems odd that this happens only on one machine. Do you get the same
problem if you run the same app on the same machine but under a different
user account?

Mike

[Bob Butler]

Post by Mike Williams

Post by Bob Butler
I deleted everything under
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32
and rebooted. When I ran the app and used file/open it displayed
full screen so I cancelled and exited the app. The registry showed
a new entry that ended ffffffff so I edited it to all zeros and tried the
app again; still full screen. I double-clicked the title bar to get the
standard size back and selected a file and exited the app. The
registry entry now ended in all zeroes but when I restarted the app
the dialog is still full screen. Something else somewhere is doing this.

It seems odd that this happens only on one machine. Do you get the same
problem if you run the same app on the same machine but under a different
user account?

No, it is just the one user. Something is corrupted in the profile but I've
already spent more time than it is worth on it.

[Mike Williams]

Post by Bob Butler
No, it is just the one user. Something is corrupted
in the profile but I've already spent more time than
it is worth on it.

Yeah, I realise that you've probably already spent more time on this than
it's worth to you, even before you mentioned it on the group. I assume that
you've already checked your code to make sure it contains nothing that might
be doing it, so the only other 'quickie' I can think of myself that might
make the problem go away is to simply rename the app, the compiled exe, but
I assume you've already tried that? Anyway, since you've had enough of it
yourself I won't mention it again.

Mike

[ralph]

On Wed, 14 Mar 2012 10:03:37 +0000, Deanna Earley

Post by Deanna Earley

Post by Mike Williams

I have the same issue with 1 app on a Vista box. When it opens
the dialog box it is maximized but double-clicking the dialog box
title bar puts it back to normal. Other apps using the same code
do not exhibit the problem and the same exe doesn't do it on
other systems. I've searched the registry and everywhere I can
think of with no luck. I've learned to live with it.

Hmm . . . that's quite interesting. I've never actually noticed it
before but it seems that Windows remembers the most recent window state
(and the size) of file dialogs on a program by program basis and that
the memory persists between restarts, so it must be in the registry
somewehere. I haven't looked for it yet but I'm sure it must be there
somewhere. Perhaps the entry has become corrupt for the specific program
you are talking about?

I quick process explorer trace shows the data to be stored as a fairly
simple binary blob under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\CIDSizeMRU
When I close the dialog, it enumerates all entries until it find the
value matching the exe name (not the full path) then updates it.
It also updates various other locations with the folder view state
(icons size, sort, etc) and the nav pane expanded state but they may be
more generic shell settings.

Wow. Am I out-of-date.

(Too many years chasing rogue controls and devices I guess. <g>)

-ralph

[BeeJ]

When you set .Flags do you use + or Or ?
If editing and you inadvertantly do something like this
Aflag + Aflag
rather than
Aflag Or Aflag
you get into trouble.

[Ivar]

Hi All

Thanks for the replies.
Multiple File Types for the File Open now sorted

After reading replies I tried this:

In VB6 IDE, Click File\Make Project Exe
The Dialog box appears Maximized (Even covers task bar) with the controls
all standard size (why so small!) in the top left.
Doube click dialog box title bar, form resizes to normal (quite small) size
in center of screen So Now fixed.
Doube click dialog box title bar again, nothing happens
Cancel That
Run Program in IDE, Click the Browse Button for GetOpenFileName
Double click title bar of the dialog box and it goes maximized and controls
reposition and resize
Go back to IDE, File\Make Project Exe and dialog box is maximized again but
controls do not resize or move

The dialog boxes in VB like Make Exe, Add New Form etc look like Fixed
Single Border style.
I learnt a little querky thingy with VB6 today, along with some other people
I expect.

Adds a little bit of fun to life :-)

thanks All

Ivar