How to control the Access Title Bar

[ApexData]

Hello

I'm using Access2000, SplitDB, ALL MenuBars are Off. The
AccessTitleBar( BlueBar) displays at the top with its (Min/Max/[X])
Controlbox.

I have a MainMenuForm (Modal-On), that Calls a ReportMenuForm
(Modal-On) that lets me select a REPORT. If I set the ReportMenuForm
(Popup-On) and I select a REPORT, the AccessTitleBar becomes disable (a
good thing), however the REPORT displays underneath the ReportMenuForm
(a bad thing). If I set the ReportMenuForm (Popup-Off) and I select a
REPORT, the REPORT displays OnTop (a good thing). However, a new
problem emerges. If the user maximizes the REPORT, the REPORTS TitleBar
disappears under the AccessTitleBar confusing the user. The user will
then press the Close[X] button, and the whole application shuts down (a
bad thing). I found unconventional code on the MS Web site, and was
able to shut off the [X] button of the AccessTitleBar, but the Min/Max
stays on.
Access2000 does not support the PopUp option in REPORTS. This would be
my solution. This MUST be a common frustration to many developers!

I need to display the REPORT OnTop, without the AccessTitleBar
concerns!

How do I disable the AccessTitleBar, or its (Min/Max[X]) Controlbox ?

[David W. Fenton]

"Larry Linson" <bo*****@localh ost.notwrote in
news:WCzrg.70$T h7.51@trnddc05:

><Ap******@gmai l.comwrote in message
news:11******** **************@ p79g2000cwp.goo glegroups.com.. .

>This problem seems to be the result of the user resizing the
ApplicationWin dow. When
the Window is expanded, it causes the botton scroll bar to
descend below the "Start Bar"
at the bottom. I'm now working on figuring out how to stop
Re-sizing of the AppWindow!

That's not the "Windows way," which is to let the user have
control over his/her own desktop, and is guaranteed to irritate
some users*. Better to let the users know that they will lose
report scrolling if they resize the window, and let it be the
user's choice.

Well, I've never understood why my users accidentally end up running
their apps in non-full-screen mode. All my apps are designed to run
full-screen at the clients' default resolutions. When they run them
at less than full-screen, they lose access to features.

And my experience is that they don't do it on purpose. They
accidentally click on something and end up non-full screen.

So, to me, preventing them from running in anything but full-screen
mode seems like not a terribly bad thing.

* some of us have been known to discard apps where the developer
decided
he knew better than we did how our screen ought to be arranged.
<G>

I can see that, but an Access app that's custom-designed ought to
have this kind of thing negotiated with the users. In that case, I
can't see it as a problem to override their ability to run in
anything but full-screen mode.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"David W. Fenton" wrote

I can see that, but an Access app
that's custom-designed ought to
have this kind of thing negotiated
with the users. In that case, I can't
see it as a problem to override their
ability to run in anything but
full-screen mode.

First, I have never had the opportunity to "negotiate with the users" but
(officially) only with a client's representative, who often neither knows
nor finds out what the majority of the users want. It's difficult in cases
where there are tens or hundreds of users, even if you know who the user
audience is.

Second, of course, if your application is not a "bespoke application," you
have to _guess_ what most users want (and my experience, unofficially, with
users is they do want to have control over their own desktop).

Third, since it is so simple for users to handle their own desktop, who am I
to force them to "do it my way," Frank Sinatra?

Fourth, if the users choose to size the Forms/Reports so that something has
to be scrolled, why should I not let them do exactly that?

Larry

[David W. Fenton]

"Larry Linson" <bo*****@localh ost.notwrote in
news:9RHrg.1279 $pB.936@trnddc0 6:

"David W. Fenton" wrote

I can see that, but an Access app
that's custom-designed ought to
have this kind of thing negotiated
with the users. In that case, I can't
see it as a problem to override their
ability to run in anything but
full-screen mode.

First, I have never had the opportunity to "negotiate with the
users" but (officially) only with a client's representative, . . .

Well, that's actually what I meant by "users."

. . . who often neither knows
nor finds out what the majority of the users want. . . .

I've never had the misfortune of lacking contact with at least some
representative end users.

. . . It's difficult in cases
where there are tens or hundreds of users, even if you know who
the user audience is.

Er, how many Access apps have hundreds of users?

Second, of course, if your application is not a "bespoke
application," you have to _guess_ what most users want (and my
experience, unofficially, with users is they do want to have
control over their own desktop).

Um, I don't think there is such a thing as a "shrink-wrap" Access
application.

Third, since it is so simple for users to handle their own
desktop, who am I to force them to "do it my way," Frank Sinatra?

In my experience, users who end up not running at full-screen
resolution in apps that are hampered by that (which would be any
Access app designed to run full-screen) don't know how to get back
to full-screen.

Fourth, if the users choose to size the Forms/Reports so that
something has to be scrolled, why should I not let them do exactly
that?

Perhaps a compromise is to always start the app full-screen and let
them do what they want from then on. The problem I've seen is that
users get into non-full-screen mode and then that is retained each
time they restart their Access app. Setting the app to full-screen
when it starts up would help out those users while not terribly
inconveniencing the user who wants to run with only part of the
screen used by the app.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[ApexData]

Perhaps a compromise is to always start the app full-screen and let

them do what they want from then on.

Hear! Hear!

Greg

David W. Fenton wrote:

"Larry Linson" <bo*****@localh ost.notwrote in
news:9RHrg.1279 $pB.936@trnddc0 6:

"David W. Fenton" wrote

I can see that, but an Access app
that's custom-designed ought to
have this kind of thing negotiated
with the users. In that case, I can't
see it as a problem to override their
ability to run in anything but
full-screen mode.

First, I have never had the opportunity to "negotiate with the
users" but (officially) only with a client's representative, . . .

Well, that's actually what I meant by "users."

. . . who often neither knows
nor finds out what the majority of the users want. . . .

I've never had the misfortune of lacking contact with at least some
representative end users.

. . . It's difficult in cases
where there are tens or hundreds of users, even if you know who
the user audience is.

Er, how many Access apps have hundreds of users?

Second, of course, if your application is not a "bespoke
application," you have to _guess_ what most users want (and my
experience, unofficially, with users is they do want to have
control over their own desktop).

Um, I don't think there is such a thing as a "shrink-wrap" Access
application.

Third, since it is so simple for users to handle their own
desktop, who am I to force them to "do it my way," Frank Sinatra?

In my experience, users who end up not running at full-screen
resolution in apps that are hampered by that (which would be any
Access app designed to run full-screen) don't know how to get back
to full-screen.

Fourth, if the users choose to size the Forms/Reports so that
something has to be scrolled, why should I not let them do exactly
that?

Perhaps a compromise is to always start the app full-screen and let
them do what they want from then on. The problem I've seen is that
users get into non-full-screen mode and then that is retained each
time they restart their Access app. Setting the app to full-screen
when it starts up would help out those users while not terribly
inconveniencing the user who wants to run with only part of the
screen used by the app.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Larry Linson]

"David W. Fenton" <XX*******@dfen ton.com.invalid wrote

>. . . It's difficult in cases
where there are tens or hundreds of users, even if you know who
the user audience is.

Er, how many Access apps have hundreds of users?

At least one, on which I did subcontract work off and on over a five-year
period in the 1990s -- when it began, the customer contract administrator
said, we now have about 35 users, but won't ever have more than 50. But,
when I last worked on it in 2000, it had between 175 and 200 users. It was a
corporate real estate database, an Access 2.0 client to an Informix server
DB. (Yes, they never wanted to pay to upgrade the client app to a newer
version, preferring to spend their development budget on enhancing features
and functions.)

On occasion, the prime contractor would have contact with a real, live user,
but not the subcontractors.

>Second, of course, if your application is not a "bespoke
application, " you have to _guess_ what most users want (and my
experience, unofficially, with users is they do want to have
control over their own desktop).

Um, I don't think there is such a thing as a "shrink-wrap" Access
application.

We get questions in the newsgroup about packaging those, fairly frequently.
They aren't general-use things like Word or Excel, but niche applications
(like corporate real-estate... this negotiated a special license to use and
modify an Access-Jet commercial app) but "shrink-wrap" is a likely
stretching it (no pun intended).

>Third, since it is so simple for users to handle their own
desktop, who am I to force them to "do it my way," Frank Sinatra?

In my experience, users who end up not running at full-screen
resolution in apps that are hampered by that (which would be any
Access app designed to run full-screen) don't know how to get back
to full-screen.

The users never seemed to have a problem in databases I've worked on, but
I've been lucky to work, mostly, with apps for users in companies where full
Office Pro was on every (pertinent) desktop. So they were not completely new
to Access/Office. Not necessarily "power users" but not "raw newbies,"
either.

Larry

[David W. Fenton]

"Larry Linson" <bo*****@localh ost.notwrote in
news:UW0sg.8561 $Wh7.826@trnddc 07:

"David W. Fenton" <XX*******@dfen ton.com.invalid wrote

>In my experience, users who end up not running at full-screen
resolution in apps that are hampered by that (which would be any
Access app designed to run full-screen) don't know how to get
back to full-screen.

The users never seemed to have a problem in databases I've worked
on, but I've been lucky to work, mostly, with apps for users in
companies where full Office Pro was on every (pertinent) desktop.
So they were not completely new to Access/Office. Not necessarily
"power users" but not "raw newbies," either.

I've never ever created or distributed a runtime app, so all of my
users are using full Access in Office Pro. They don't understand the
basics of handling windows because nobody has ever given them any
training, so they get in situations that they don't understand and
just live with them.

At least, that's my experience with the 100s of users I've worked
with in the 12 years I've been a computer consultant. YMMV.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/