Re: Advice Needed...

"Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:uc3kdcPnHHA.3968@xxxxxxxxxxxxxxxxxxxxxxx
Possibly, though even with A97 databases, it will still run them without
converting. You just have to tell them not to convert. But if it's a
problem, then you distribute the Access runtimes, which avoid the problem
altogether.

Usually you can get around these issues but these are the sort of problems
you get with access.

Actually, it simply reverses forecolor and backcolor when highlighting,
which is desirable, cuz you don't want to highlight blue text with a blue
background.

What is desirable for me is having the windows look. Windows uses blue.

The checkbox looks wrong when grayed out.

It does? Looks fine to me.

Have a look here. The hatched pattern is wrong.
http://mikesdriveway.com/misc/access.jpg

Again, what looks wrong about it? Looks fine to me when I click on
it...it depresses, as I'd expect.

A pressed button in windows should be flat, not indented.

As for not selecting until you release, I've never heard of anybody
actually holding it down, but if you really felt the need to support that,
you could probably rig something.

Then you'd need to code something just to get back to where it should be.
Likely it would be complicated and require subclassing.

Failing that, you can always import a Forms 2.0 combo box if you feel that
strongly about it.

You could but it would be nice if it just worked as it should.

The combo button also doesn't look right when not pressed because the
array is too small.

I assume you meant arrow. This is the first time I've ever even noticed
that, but I can't imagine anybody would care all that much. Again, you
can use a Forms 2.0 combo if you really feel the need.

I don't think people will actually notice the arrow is too small but many
will notice something is wrong with the general look of the app. Until this
post I didn't notice all the specifics myself but just noticed that it looks
wrong.

The buttons look wrong when pressed (they go inverted instead of flat).

This actually bothers anybody? I've never even noticed the difference,
myself. Even looking for it, I barely notice the difference. I doubt if
any standard use actually notices these things.

Access developers don't seem to notice these things for some reason. Other's
do. As I said they don't generally notice all the specifics but they
describe the forms as ugly. To me it just looks unprofessional.

The corners of a frame are wrong if you look close enough and the button
on the combo is 1 pixel to the left too many.

Not sure what you mean here.

If you look at the frame zoomed and compare to a real windows frame the
corners of the access frame are wrong. With the combobox the button is 1
pixel to the left of where it should be (there is a 1 pixel gap between the
button and the border).

Why not? They're all so close to the originals in general appearance, the
behaviour is close enough that only the most attentive of users would even
notice, and likely not care, and I find the controls have equivalent or
better functionality for the most part.

They're not that close. I've written controls before and made every effort
to get them pixel perfect. The access developers have made little effort at
all.

To me, of FAR greater concern in a professional looking app are things
like control alignment and sizing, use of colour, fonts, or frames to
highlight key areas, and that sort of thing. All these things can be done
equally well in either app, though my experience is that because it's a
little more laborious in VB6, form creators tend not to spend their time
on it, which leads to a greater likelihood of unprofessional looking
forms.

Given equal developers though the VB forms will look far better. Generally I
find access developers tend to be quicker in their development so VB forms
come out better. To me (a VB developer) the access controls look aweful. You
(an access developer) still don't notice the problems when they're pointed
out. Don't take this as an insult because it is not meant to be. Access
developers are usually working on in-house apps so are more concerned with
getting the job done.

Another one that someone asked me about, maybe about two months ago...I
was asking if there were any upgrades that my users would like to see in
my app, and one of them asked me if I could change it so that when you
enter a field, the entire field is highlighted instead of just going to
the first character. I directed him to "Tools", "Options". :-) I'd like
to see you implement THAT in a VB6 program. Easy enough on a single-case
basis, but per user for every control on every form? I'll grant, that's
more of an environment thing, but it's the sort of flexibility that many
users like that's simply not available in a VB6 form. And, of course,
there's all the shortcut keys like insert date and copy field from
previous record that are all pre-defined in Access and incredibly useful
in a database-driven app.

You allow them to see the options form? This is exactly the sort of thing
I'm talking about. A real app would not have an options form that allowed
them to select whether or not to show system queries etc. I also prefer the
VB6 model where you have to add this functionality yourself. The textbox
example you gave could be implemented fairly easily. Although as it is
default windows behaviour it should be turned on always.

On the design side, the addition of the form/page header/footer sections
is also nice. Obviously not as useful in an environment where you don't
have continuous forms to worry about, but really handy in a data
environment, or one where you expect to print your forms.

I'm not a big fan of repeating textboxes etc over and over. I'll just use a
grid or have next/previous buttons.

AFAIK, they behave the same. About the only thing that I don't *think*
you can do is to hide the Access application window and JUST display your
own form. I don't see that being too big of a deal for most apps, but I
can certainly see it being annoying if you have some desperate need to do
so.

There is definately something you can't do that is fairly common. I can't
remember what it is.

What huge functionality? Don't take that the wrong way, I'm not saying
it's not there, but in my limited experiences with .NET, I haven't seen
anything I consider to be all that useful.

When designing your own controls there is an *extensive* amount of
functionality available in the ComponentModel namespace (from memory).

Oh, and resizing strictly via the property window? Wow...that must take
you a long time to move, size, and align things! That's another one I've
never liked about VB6 is the lack of a design-time size-to-fit feature.
The AutoFit property is about the closest you can get, and it's a sorry
substitute for design-time functionality. (That said, I wish some Access
controls had the AutoFit functionality available at run-time, so I guess
it's a toss-up on that one.)

I don't resize everything from the property window, just fine adjustments.
If it's not exactly where I want I add or subtract multiples of 15 twips
until it is right. If I want to align controls I just copy/paste to the Top
property for example.

I don't often have call to do that. In point of fact, I've only done it
once, and not very successfully. (Oh and I'll give you this one: you
can't do this at ALL in Access. <g>)

I do it a lot. I made my own designer in one app so users could design their
own printouts. Much of the .net designer was available as controls that I
could plonk on my form.

Nice. That *is* one of the nicer things about .NET, I'll grant, though
I'm still waiting for it to exhibit similar speed to VB6/VBA before I
start any mass-migrations. I gather they're improving in VB 2005, but
still not quite there yet as I understand it. Truthfully, in my
environment, I doubt I'll ever port much of my code to VB 2005; too steep
of a learning curve, and I truly don't have that kind of development time.
(Sole developer with constant changes to business rules and sometimes even
underlying design to keep up with...oh yay. What can I say, senior
management at my company has a reputation in the local IT community, and
not a good one.)

Do you work for the same company as me? ;-)

With other versions, though, they're potential issues which can only be
had if corporate IT people locked down your machine and knew darn well
what they were getting themselves into. With Vista, you run into it on
EVERY machine that's not specifically altered to avoid it. You also knew
that if you put a file in one place, that's where it went (ignoring the
more funky things like junctions, etc.). But nobody at our company is
likely to have Vista for some time yet, so those concerns are on the
distant horizon for me. I mean, we only started getting XP on our
machines about a year ago!

That's true although with XP it is easy to login as guest. We encounter
these issues quite a bit. We have a bit of a joke around the office that the
first thing you tell customers with an issue to do is reboot, the second is
to reinstall as admin.

Yes, but not even 1 is an option in VB.NET. I think that's a bigger issue
for me than the ad hoc numbers. Other number are nice-to-have's, but
hardly critical.

The only reason I used 1 is because of limitations of VB (you can't dim from
0 to -1 as you should be able to).

Michael


.

Loading