 | |
Possible to tell what data type a control on a form contains?
comp.databases.ms-access comp.databases.ms-access
 |
| | Thread Tools | Display Modes |
#41
 
| |||
| |||
|
Re: Possible to tell what data type a control on a form contains? -
07-17-2011
, 04:49 PM
|
David-W-Fenton wrote: "Bob Barrows" <reb01501 (AT) NOyahooSPAM (DOT) com> wrote in news:ivn71h$m9g$1 (AT) dont-email (DOT) me: Yes, the developer can mitigate this but many think it should be the other way around: the default behavior should be to ask the user if changes should be saved and it should be up to the developer to modify that behavior. I imagine it's similar to the distaste for opt-out vs. opt-in. If you don't like this default behavior of Access (which I consider to be vastly superior to the alternative), then you really should stop using Access, because working around it entirely means going unbound, and if you're doing that, you've thrown out 90% of the advantage of Access. I believe it would be possible for Microsoft to make forms work either way. |
Bound data needs to be saved automatically. Otherwise, you end up
with worse problems (like the early days of websites where it was
really easy to lose edits to your HTML forms if the user didn't know
they had to click the SAVE button; many websites now have autosave
set up so that doesn't happen; hmm -- sounds suspiciously
familiar....).
Quote:
|
An "Auto Save" property that one can turn on or off. When set to False, an extra Save button is automatically placed on the form (with each record in the case of a continuous form), and a warning is presented to the user whenever he does something that could cause data changes to be lost. |
be providing a feature I've never needed even once.
Quote:
|
Jeez. Let's not get religious here. There's one tiny little bit of Access that somone dislikes so that person should "just stop using it"??? What kind of thinking is that? |
wax. The automatic save is a result of the bound nature of Access
forms. You can't just toss that and have it simply work exactly the
same.
Consider in your scenario:
How would the form-based events work in the event of having Autosave
turned off?
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#42
| |||
| |||
|
|
On 15 Jul 2011 18:38:06 GMT, "David-W-Fenton" NoEmail (AT) SeeSignature (DOT) invalid> wrote: "Bob Barrows" <reb01501 (AT) NOSPAMyahoo (DOT) com> wrote in news:ivpa5f$bjc$1 (AT) dont-email (DOT) me: Patrick Finucane wrote: If you have data that makes the form dirty it will run the BeforeUpdate event thus you can cancel it. Well, yeah! In other words, developers are being forced to "opt-out" of the undesirable behavior rather than opting in. If you consider that behavior undesirable, then STOP USING ACCESS. Everything in Access is designed around the concept of bound data. You don't like that, so you really shouldn't be using Access at all. Do you have users/clients that call you and ask where certain new records and edits come from since they didn't save what they were working on? |
creation and record editing functions into two separate forms, with
the ADD NEW form being unbound, and the main form being used for
edits. Thus, one form doesn't have to do two things, and automatic
saves of records that the user wants to cancel don't happen.
Quote:
|
We had to put a save button on all our forms. I find it frustrating as heck also to have things automatically get saved. Also to have the save button dimmed out when I've made a change. Dreamweaver does that for instance. Other MS products don't do that crap (besides back ups). |
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#43
| |||
| |||
|
|
"Bob Barrows" <reb01501 (AT) NOSPAMyahoo (DOT) com> wrote in news:ivq2o5$f9a$2 (AT) dont-email (DOT) me: David-W-Fenton wrote: "Bob Barrows" <reb01501 (AT) NOyahooSPAM (DOT) com> wrote in news:ivn71h$m9g$1 (AT) dont-email (DOT) me: Yes, the developer can mitigate this but many think it should be the other way around: the default behavior should be to ask the user if changes should be saved and it should be up to the developer to modify that behavior. I imagine it's similar to the distaste for opt-out vs. opt-in. If you don't like this default behavior of Access (which I consider to be vastly superior to the alternative), then you really should stop using Access, because working around it entirely means going unbound, and if you're doing that, you've thrown out 90% of the advantage of Access. I believe it would be possible for Microsoft to make forms work either way. While anything is possible, I would say it would not be DESIRABLE. Bound data needs to be saved automatically. Otherwise, you end up with worse problems (like the early days of websites where it was really easy to lose edits to your HTML forms if the user didn't know they had to click the SAVE button; many websites now have autosave set up so that doesn't happen; hmm -- sounds suspiciously familiar....). An "Auto Save" property that one can turn on or off. When set to False, an extra Save button is automatically placed on the form (with each record in the case of a continuous form), and a warning is presented to the user whenever he does something that could cause data changes to be lost. I can't see how this would improve Access in the slightest. It would be providing a feature I've never needed even once. |
couple times (the tradeoffs that sometimes need to be made between quick
develoment time and having everything your own way, for example), but for
the most part, users accepted the way it worked.
Quote:
|
Jeez. Let's not get religious here. There's one tiny little bit of Access that somone dislikes so that person should "just stop using it"??? What kind of thinking is that? It's not a "tiny little bit of Access" -- it's the whole ball of wax. The automatic save is a result of the bound nature of Access forms. You can't just toss that and have it simply work exactly the same. Consider in your scenario: How would the form-based events work in the event of having Autosave turned off? |
series of "edicts issued from on high". :-)
As to your question, i would imagine the events would work the similarly to
the way they do in VB, where the developer has to code in all the actions
that are taken automatically now in Access. It is all a trade-off. There
were times when I was working with VB that I wished it did the things for me
that Access did.
#44
| |||
| |||
|
|
PW <emailaddyin... (AT) ifIremember (DOT) com> wrote innews:kv7127ti2qo9fvme0293sa10c4crj2662i (AT) 4ax (DOT) com: Do you have users/clients that call you and ask where certain new records and edits come from since they didn't save what they were working on? No, I don't. I've explained my methods: I separate the record creation and record editing functions into two separate forms, with the ADD NEW form being unbound, and the main form being used for edits. Thus, one form doesn't have to do two things, and automatic saves of records that the user wants to cancel don't happen. |
for the bound data and rolling up the changes at the end. I would
skip using the temporary table if I could get away with it for the
number of users I have. The 'new vs. edit' distinction seems to be a
pretty sensible approach.
Quote:
|
*We had to put a save button on all our forms. *I find it frustrating as heck also to have things automatically get saved. Also to have the save button dimmed out when I've made a change. Dreamweaver does that for instance. Other MS products don't do that crap (besides back ups). Other MS products don't provide bound data. |
as in Access. WinForms, Windows Presentation Foundation (WPF) and
Windows Communication Foundation (WCF) - all available from Visual
Studio (VS) - seem to have different binding options available for
specifying how data is bound. I've even seen a PDC 08 session
recently (perhaps TL 58 - Research: Concurrency Analysis Platform and
Tools for Finding Concurrency Bugs) that talked about using VS in
conjunction with either optimistic or pessimistic locking. But as
others have mentioned, it takes many times longer to set everything up
in VS than in Access. Even so, you'd be surprised at the number of VS
developers that do Access-like applications, many with only a
smattering of T-SQL knowledge.
James A. Fortune
CDMAPoster (AT) FortuneJames (DOT) com
#45
| |||
| |||
|
|
Even so, you'd be surprised at the number of VS developers that do Access-like applications, many with only a smattering of T-SQL knowledge. |
(VS and other) developers who had only a "smattering of any kind of database
knowledge" had the temerity to create database applications.
--
Larry Linson, Microsoft Office Access MVP
Co-author: "Microsoft Access Small Business Solutions", published by Wiley
Access newsgroup support is alive and well in USENET
comp.databases.ms-access
#46
| |||
| |||
|
|
As to your question, i would imagine the events would work the similarly to the way they do in VB, where the developer has to code in all the actions that are taken automatically now in Access. It is all a trade-off. There were times when I was working with VB that I wished it did the things for me that Access did. |
writing unbound forms. We can already do that, so there would no
advantage to MS adding in the option to turn off AutoSave.
That was really my point in asking the question...
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#47
| |||
| |||
|
|
"James A. Fortune" <CDMAPoster (AT) FortuneJames (DOT) com> wrote Even so, you'd be surprised at the number of VS developers that do Access-like applications, many with only a smattering of T-SQL knowledge. I have always been amazed, even 'back in the day' of classic VB, how many (VS and other) developers who had only a "smattering of any kind of database knowledge" had the temerity to create database applications. |
database design are committed. There are literally 100s of thousands
of web developer out there creating horrid databases without any
sense of normalization or any other of the most basic best practices
in database design.
They make your stereotypical Access novice look like a genius.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#48
| |||
| |||
|
|
On Jul 17, 5:51*pm, "David-W-Fenton" NoEm... (AT) SeeSignature (DOT) invalid> wrote: Other MS products don't provide bound data. I'm not so sure about that. Perhaps you mean in a way that is as easy as in Access. WinForms, Windows Presentation Foundation (WPF) and Windows Communication Foundation (WCF) - all available from Visual Studio (VS) - seem to have different binding options available for specifying how data is bound. |
from reading about it, but I don't think they really have bound data
in the sense that Access does. What they have is components one can
use that make it SEEM like you've got bound data, so you can work
like you would in Access, and the components take care of the
updating (just like in Access), but the data is not actually bound
in the way it is in Access.
But my understanding of that could be wrong.
And, indeed, in writing that, I realize I'm not sure how I'd even
define "bound the way it is in Access."
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
#49
| |||
| |||
|
|
"Bob Barrows" <reb01501 (AT) NOSPAMyahoo (DOT) com> wrote in news:ivvq7d$df5$1 (AT) dont-email (DOT) me: As to your question, i would imagine the events would work the similarly to the way they do in VB, where the developer has to code in all the actions that are taken automatically now in Access. It is all a trade-off. There were times when I was working with VB that I wished it did the things for me that Access did. In other words, if AutoSave were turned off, it would be like writing unbound forms. |
data-bound controls work - the bound controls would automatically populate
with the data from the objects to which the controls are bound, record
navigation would still be automatic with no code needed to make it happen,
etc. All the things we love about bound forms, without the "auto-save".
#50
| |||
| |||
|
|
David-W-Fenton wrote: "Bob Barrows" <reb01501 (AT) NOSPAMyahoo (DOT) com> wrote in news:ivvq7d$df5$1 (AT) dont-email (DOT) me: As to your question, i would imagine the events would work the similarly to the way they do in VB, where the developer has to code in all the actions that are taken automatically now in Access. It is all a trade-off. There were times when I was working with VB that I wished it did the things for me that Access did. In other words, if AutoSave were turned off, it would be like writing unbound forms. Well no, perhaps I misspoke or you aren't familiar with how VB forms with data-bound controls work - the bound controls would automatically populate with the data from the objects to which the controls are bound, record navigation would still be automatic with no code needed to make it happen, etc. All the things we love about bound forms, without the "auto-save". |
- .Dirty property/event
- .BeforeUpdate/AfterUpdate events
- .OnInsert/OnDelete events
....and so forth. Does VB have all of those? I strongly doubt it. And
an unbound Access forms loses all of them. I can't imagine keeping
the same events if you turn off AutoSave, as some of them become
kind of nonsensical.
To me, this is a proposal to solve a problem that doesn't really
exist in the first place, except in the minds of people who are
anti-Access in their desired befavior. In short, they should be
programming in some other environment.
--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.