Re: Advanced Queries



"Me!ControlSourceName" used in code cannot determine whether you are
referring to the name of the Control, if you have named it the same, or the
underlying Field in the Record Source that you have used as Control Source.
Which of the two would you want Access to use? Which of the two does it
actually use?

Frankly, if you have used that for years and years without bad result, I
have no problem with your continuing to do so. I do have a problem with your
repeatedly advising others to do so, (and giving you the benefit of the
doubt:) without realizing you may be leading them to a bad result.

The fact that the Microsoft-supplied Wizard does so is not germane, and most
certainly does not imply that it can never be a problem.

Anytime, my friend, that Lyle and I agree, you should take heed, because we
differ on a great many matters of opinion, so our areas of agreement are
more often than not, matters of fact.

Larry Linson
Microsoft Access MVP



"DFS" <nospam@xxxxxxxx> wrote in message
news:7ebUf.489$Pe.360@xxxxxxxxxxxxxxxxxxxxxxxxx
Lyle Fairfield wrote:
DFS wrote:
Lyle Fairfield wrote:

What it underlies is the fact that MS actually recommends this
convention. Microsoft vs Lyle Fairfield/Larry Linson? Let me
think...

It's a tough choice. I don't know whether I'd be too hot on the
Linson/Fairfield advice, (they're both old and Alzheimerish) but if MS
recommended something I'd be looking at it pretty skeptically.

That's a little cynical (maybe a little exaggerated for your cdma
audience?), though in some respects not a bad position.

But if screen control=column name was a Really Bad Thing as some are
implying, the Access Autoforms wouldn't default to it.

Have you used OpenOffice 2.0 Base? It does the same thing. As I recall,
Borland Paradox for Windows did, too.



BTW I have old code that goes through all my forms and renames
controls using prefixes like "txt" and "cbo" and specifically ensures
that bound controls do not have the same name as the field to which
they are bound.

Why? Any particular problems that you've observed that led you to write
such code.

BTW I have old code that goes through all my forms and renames controls
and
specifically ensures that bound controls do have the same name as the
field
to which they are bound. (LOL! I'm not kidding)



I'm glad you have had not problems and perhaps I should review my
position on the matter. Since I don't make so many Access Forms
anymore that may be a while.

Thank you for not continuing an argument. cdma should be a place of peace
and solitude and swift code...





.



Relevant Pages

  • Re: Data-Bound is BAD???
    ... Corner of my heart i still feel that there is a goldmine in Bound Controls ... > Custom data source controls provide you with almost limitless ... > you can use them to process connection and recordset events, ...
    (microsoft.public.vb.database.ado)
  • Re: Data-Bound is BAD???
    ... Data Bound controls add additional ... Actually what you're describing is a limitation of the stock *data source ... you can use them to process connection and recordset events, ... I realize I'm one of the few advocates of bound controls that regularly ...
    (microsoft.public.vb.database.ado)
  • Re: Last Edited record on Subform.
    ... Sylvain Lafontaine, ing. ... are they bound or unbound controls? ... to change the values in bound controls and update the tables? ... report of bugs with Me.RecordsetClone and ADP. ...
    (microsoft.public.access.adp.sqlserver)
  • Re: Locking bound controls-AllenBrowne
    ... The code toggles the Locked state of the bound controls. ...
    (microsoft.public.access.formscoding)
  • Controls which support Transparent background
    ... Framework and Microsoft vision of the future. ... VDS offers you complete set of Visual Controls, ... Separated modules for run-time and design time modes. ...
    (microsoft.public.dotnet.framework.compactframework)