A2010 macro builder and a message box
in [Help]
|
Prev: Help in A2010
Next: New features of Access 2010
From: Albert D. Kallal on 27 Nov 2009 18:08 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CD09CDBD7DC4f99a49ed1d0c49c5bbb2(a)74.209.136.97... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:NNCPm.25289$Sw5.16776(a)newsfe16.iad: > >> While this programming model is nothing like being spoiled with >> VBA, the whole macro design and setup for web forms is simple, >> elegant, and IMHO simply brilliant.... > > There does seem to be something of an arithmetic growth problem, > with embedded vs. non-embedded macros TIMES web vs. client. Well, sure, but it really a question of distinguishing issues here. I mean, a standard code module, and class object module are not the same as a forms code module for example. You can use "me" in a standard forms VBA module, but not in a code module, or an class code module that you create. So, that's 3 different kind of code modules right there, and we could argue that reports code modules are a 4th one. As an "general" rule, we don't have to state what kind of module, but if I asking an question about a report and why I can't use me.FieldName in a reports code module, then it is clear. As you know, in a forms code module, you do NOT have to place text boxes on the form to reference/use fields in vba code, but in a reports code module, you DO HAVE to place text boxes on the report to reference any field in the reports data source. So, the feature set and what you can (and can't do) varies quite a bit depending on what kind of VBA module you are talking about. The same issue arises here for macros. In fact it more pronounced since the feature set change is MORE dramatic from one type of macro to the next, so, it does become important to distinguish what type of macro one is talking about, just like it important to talk about what kind of code module we are talking about -- even how VBA forms code modules work compared to report code modules is quite different. > > I'd assume that a client form/report can call a web macro while a > web form/report can't call a client macro? > yes, since if you looked at the nav pane, you see a list of web and non web macros in that list. You can launch/run any of them by just clicking on a macro. And, the while in theory it would be possible for a web form to call a client macor **if** we running local and not on the web. However, if running web, then that form would not have the client macro available. In fact, what happens where is the macro "drop down" of legal macros is restricted to web only during coding to prevent you from typing in any non legal name. Note that web reports do not have any code or events... > I'd also assume that table-level data macros are callable by either? > > Yes, no, maybe? Yes, either can call the data macros. Since the data macros exist both local and web, then they again are callable by both client and web forms. In fact, the real question here does a call to a data macro in the client execute code local in ACE, or is the call passed to SharePoint? I don't know right now.. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 28 Nov 2009 23:15 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:FZYPm.36883$ZF3.470(a)newsfe13.iad: > You can use "me" in a standard forms VBA > module, but not in a code module, or an class code module that you > create. So, that's 3 different kind of code modules right there Wrong, Albert. Standalone class modules can use Me just like form/report class modules. It's because they are both CLASS MODULES. The fact that one is attached to a form/report and one is not does not change something as basic as that. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 28 Nov 2009 23:18 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:FZYPm.36883$ZF3.470(a)newsfe13.iad: > So, the feature set and what you can (and can't do) varies quite a > bit depending on what kind of VBA module you are talking about. I think that both of your examples are wrong, Albert. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 28 Nov 2009 23:17 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:FZYPm.36883$ZF3.470(a)newsfe13.iad: > As an "general" rule, we don't have > to state what kind of module, but if I asking an question about a > report and why I can't use me.FieldName in a reports code module, > then it is clear. As you know, in a forms code module, you do NOT > have to place text boxes on the form to reference/use fields in > vba code, but in a reports code module, you DO HAVE to place text > boxes on the report to reference any field in the reports data > source. I do *not* know this to be the case. Access 2000 made forms less robust in that it is unsafe to refer to underlying fields (such that you have to add hidden controls bound to them if you need to refer to their values). I haven't stopped doing it, but it doesn't always work. I would assume this had something to do with the change of storage of the VBA project, and so far as I know, reports work exactly the same way. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 29 Nov 2009 10:02
"David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CD1EC8999FC6f99a49ed1d0c49c5bbb2(a)74.209.136.90... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:FZYPm.36883$ZF3.470(a)newsfe13.iad: > >> You can use "me" in a standard forms VBA >> module, but not in a code module, or an class code module that you >> create. So, that's 3 different kind of code modules right there > > Wrong, Albert. Standalone class modules can use Me just like > form/report class modules. Yes, sorry, my bad... I meant to say me.FieldName, not me. I was not trying to state that you can't use me in a class module. (I do that all the time). The "basic" point here was that even a forms code module behaves different then a reports code module for example. And, so does a standard class module that is not attached to any form. So, a question as to why me.FieldName don't work in a reports module is a DIFFERENT question then that of using me.FieldName in a forms module. So, me.fieldName usually works in a form (regardless if their is a text box on the form, but in the format events in a reports code module, me.Fieldname don't work unless a text box is placed on the report that is bound to the column. We often see questions in this newsgroup where someone moved their code from a forms code (class) module into an standard code module (or even a class code module), and then wonder why they can't use me.fieldName anymore. In a nutshell, my "point" here is that while do seem to have "quite a few" names for macros, it not a whole lot different then that of the several types of class modules we have (forms, reports, class modules). I simply just spent some extra time to point out the terminology we have for macros, and one will often need to distinguish between the different types when discussing them.. -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com |