Minimize and Maximize Forms continued

[Geoff]

To Harald Staff, for others, please see my first query
dated 13th, now 4 pages back!
Your comments on FormFun and 'real' VB6 forms are most
interesting. I have very recently(ie yesterday) been
given access to VB6 but have never used it before. I did
note however the automatic install of minimize/maximise
buttons on forms and this may offer a quick solution to
my problem though not without some required learning.

I have just finished what to me is a sizable wbook
project in VBA, in all nearly 6000 lines of code. My aim
was always to work within the constraints of a modal
form. After thorough testing I have not had any code
based bugs from the users so far. However, the users now
say they can get incoming queries which may demand
accessibility to other applications. This means either
closing the data input form with loss of data etc or
delaying their responses hence the request for
minimize/maximise functionality and my dilemma. This on
the one hand is to try and comprehend FormFun's code (no
criticism intended) and adapt it to my project or go on a
quick learning curve and create a VB6 addin with all the
necessary window state precautions etc. The latter means
I would also have to re-think my strategy on menus as for
simplicity I have used six autoshapes each with a macro
attached.

So a VB6 solution is not without a lot of effort but you
suggest a VB6 'real' form is the more robust way. I
accept your experience but why do you feel a FormFun
adaptation is perhaps less robust and do the misgivings
involve minimize/maximize functions?

Thanks for the thought provoking comments so far.

Geoff

 

[Harald Staff]

Hi Geoff

My few testings with FormFun for this asssumed that you want a resizable
form and a modeless form. A standard userform can be used like
Userform1.Show vbModeless

and it's modeless, you can access the worksheet, the menus, anything. Try
that too with FormFun's "Show" and it's modeless, ok, but after unloading
everything locks up. It's own Modal toggle will allow you to access the
worksheet, but not the Excel menus. And it's made with quite a few Windows
API calls that, unless you really understand them, may cause problems during
programming and also running. I have not yet succeeded in making it behave
real modeless and may well never get there... If you can live without
maximize-minimize and accompanying Windows code then things are far far
easier; fixed-size modeless form and that's it.

My VB6 idea is based on its robust form design using quite standard
components. It is by no means easy to do either, except that VB6 and VBA use
the very same language engine. Here's an article on how to get started with
an Office add-in:
http://support.microsoft.com/?kbid=238228
but don't go that way unless you really want this to be fantastic or you
feel that the experience and knowledge is valuable.

I guess I'm expected to promote the new Visual Studio Tools for Office too,
but they are only for latest Office version, Windows XP and language
VB.Net -if you feel that VB6 has a steep learning curve then that's
vertical. But really good once there, and in near future the only way to do
it I guess.

There are btw ways to store form settings/data and reload them, so if
loosing data on unload/reload is the real concern then it can be solved.

 

[Tim Zych]

From what I've seen, MS Office's forms/controls are more advanced than VB's.
I'd rather use an Office listbox rather than a VB6 listbox. Multi-column,
fill it with an array, column headers. I don't believe VB has these
capabilities. I guess it depends on what you want to sacrifice in order to
use a "real" form.

 

[Harald Staff]

From what I've seen, MS Office's forms/controls are more advanced than VB's.
I'd rather use an Office listbox rather than a VB6 listbox. Multi-column,
fill it with an array, column headers. I don't believe VB has these
capabilities. I guess it depends on what you want to sacrifice in order to

Very wrong Tim. Thing is, you have to code lots of things into VB6 components that VBA
Forms2 components are pre-coded with, like combobox autocomplete. You don't use a VB6
listbox, but either a listview or a grid, for multicolumn tasks. And you are bothered with
fewer bugs and annoying lack of features / events than with the pre-coded toys. So
"sacrifice" is not the word.

Best wishes Harald
Followup to newsgroup only please.

 

[Geoff]

Harold and Tim,
Seems as thought there are devotees for both systems but
as I must have a stable environment and my users request
a minimize function then it's the steep learning curve of
VB6 ahead of me now. It's steep because I have so little
time to play with.
Thanks to both for the enlightening debate.

Geoff

-----Original Message-----
sacrifice in order to

Very wrong Tim. Thing is, you have to code lots of

things into VB6 components that VBA

Forms2 components are pre-coded with, like combobox

autocomplete. You don't use a VB6

listbox, but either a listview or a grid, for

multicolumn tasks. And you are bothered with

 

[Harald Staff]

Wish you the best of luck Geoff. Deadlines are no fun, but learning something new is.

This is the place to post when it comes to the Excel object model and Excel interaction.
For more general VB6 things, let me recommend the newsgroup
microsoft.public.vb.general.discussion. Connect directly to newsserver
msnews.microsoft.com if your ISP don't provide it.

Also, feel free to email me at harald dot staff at nrk dot no if you're stuck on something
that you think I might know and I'll see if I can be of help. Enclose your name in the
subject field and attatch no files, we have a far too strict firewall.

Best wishes Harald
Followup to newsgroup only please.

 

[Tim Zych]

Harald:

you have a point..."sacrifice" probably was too strong a word. I was
responding to the OP's use of a "real" forms, and how XL's forms and their
controls (listboxes) were implied not to be. How untrue that is...

As far as claiming that XL's controls are more advanced, we do have the
ability to create multiple columns in an XL combo/listbox, and fill it in
one fell swoop with an array. Transfer to a worksheet is just as simple.

If all the OP needs to do is to unload the form while retaining the values,
why not use the ControlSource property or other means of storage? It seems a
bit drastic to toss it aside and use a VB form, in conjunction with the XL
workbook, for the needs as stated.

To add, I am not bothered by the features in VBA's controls (trying to think
of which ones you had in mind). And I don't know of many bugs, no more than
would be expected.

"Toys"?
Do you really mean this?

(I guess the C++ folks could say the same thing about VB/VBA).

Tim

 

[Harald Staff]

Hi Tim

Guess we shouldn't extend this tread further but it's hard to resist a
thread that's not about times calculations ...

I was
responding to the OP's use of a "real" forms, and how XL's forms and their
controls (listboxes) were implied not to be. How untrue that is...

I introduced that in prev thread, "real" in quotes at the time.

If all the OP needs to do is to unload the form while retaining the values,
why not use the ControlSource property or other means of storage? It seems a
bit drastic to toss it aside and use a VB form, in conjunction with the XL
workbook, for the needs as stated.

Agreed. But Geoff just has to deliver resizable modeless forms if I read
this thread correctly.

To add, I am not bothered by the features in VBA's controls (trying to think
of which ones you had in mind). And I don't know of many bugs, no more than
would be expected.

I use the events activate/deactivate, gotfocus/lostfocus, enter/exit a lot,
maybe more than the average coder, I really need them for all my validation
and calculations. I find these events too unreliable and/or buggy in Forms2
to be of much use.

"Toys"?
Do you really mean this?

Yes.But I'm male and don't dislike toys. I make lots of userforms, quite a
few dialog sheets (!) and lots of VB6 forms. Toys for toy jobs, no problem

(I guess the C++ folks could say the same thing about VB/VBA).

Definitely true <bg>

Best wishes Harald

 

[Tim Zych]

Perhaps we should continue this in another thread or privately...but...

are you referring to an ActiveX dll? Do you have any issues with deploying
these to users? How do you go about doing this (what tools do you use to
distribute?)

 

[Harald Staff]

are you referring to an ActiveX dll? Do you have any issues with deploying
these to users? How do you go about doing this (what tools do you use to
distribute?)

I make exe's, dlls, ocx'es and xla's. Everything has been like this: I have some pages on
our intranet where users could read about what's there, click/run Setup.exe (made by
great&simple Setup Factory) and that's it. Everything I make is distributed this way. My
smarter apps even look for newer versions of itself and replaces themselves if so.

In a couple of months we're forced to use WinXP Pro all over, strict rules, no user
priviledges except perhaps a keyboard and a mouse if you're nice, and centralized MSI
packages (InstallShield Developer only) for absolutely everything, deployed part by
ActiveDirectory/user profiles and part by some other logic that I don't yet get. I
honestly don't know what I'm going to do or wether anything will work or even if I will
have work myself. But what I read about of deployment theories, signed versions, yada
yada, is not what I face in real life, that's too sure...

Best wishes Harald