A2010 macro builder and a message box
in [Help]
|
Prev: Help in A2010
Next: New features of Access 2010
From: Salad on 25 Nov 2009 02:28 Thanks to Albert I was able to look at a help file. It took some doing because the hsx viewer told me MS Help 2.x runtime wasn't available. So I had do dl something from Microsoft, in this case VB.Net, to get the required runtime files. I didn't explore them much so I may be asking a question that is contained in the file. How can one display a msgbox from a macro? I've been real curious about CurrentWebUser and what the values and parameters were. So I created a couple of statements messagebox "0 " & CurrentWebUser(0) messagebox "1 " & CurrentWebUser(1) messagebox "2 " & CurrentWebUser(2) messagebox "3 " & CurrentWebUser(3) saved the macro and form and ran and it displayed "0 " & CurrentWebUser(0) "1 " & CurrentWebUser(1) "2 " & CurrentWebUser(2) "3 " & CurrentWebUser(3) So I created a temp variable SetTempVar One Value :1 + 1 messagebox "One " & 1 + 1 messagebox One and the results were "One " & 1 + 1 One In older VBA, I could do msgbox "Today is " & Date() and it would display Today is 11/23/2009 I noticed the help had a lot of missing links. In the help file I got from Albert's link I was informed that data would be provided in the help file when A2010 was released. I know there's got to be a way to display a calculated string in a message box. But without a book detailing some of this stuff, the method to learn the how-to's of A2010 seems to beby trial and error, guessing and by-goshing, and flying by the seat of one's pants. If anyone knows how to display a calculation of a messagebox from a macro and willing the pass that info on that would be appreciated.
From: Albert D. Kallal on 25 Nov 2009 09:03 "Salad" <oil(a)vinegar.com> wrote in message > If anyone knows how to display a calculation of a messagebox from a macro > and willing the pass that info on that would be appreciated. I quite sure how this works goes all the way back to access 95, or even before that.... Think of that message box as how you type in a expression in a property sheet in ms-access (you have to force the expression service to take care of this). so: Hello or "Hello" Will be taken as an literal To avoid confusing, I just always use the expression service in macros, and hence: =("Hello") so, you code might go: SetTempvar (i,1) messagebox =("Value of I = " & [TempVars]![I]) So, it really the same as using expressions in ms-access... You need to put =() and you have an expression... Here is a screen shot of a macro that sets a value, and then runs a loop 5 times display the value 5 times (the message box will appear 5 times). http://cpedvw.bay.livefilestore.com/y1pV0NrTr6kZF89YQf6BnUUodaeTLeRvn9_znWYBrHZKr5JCUedqGnmHsCA1Dcxs4lMzlYvzeeMBDNSd5M-Ex-8OIzImfqdlmpY/macr1.png -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: Salad on 25 Nov 2009 10:39 Albert D. Kallal wrote: > "Salad" <oil(a)vinegar.com> wrote in message > > >>If anyone knows how to display a calculation of a messagebox from a macro >>and willing the pass that info on that would be appreciated. > > > I quite sure how this works goes all the way back to access 95, or even > before that.... > > Think of that message box as how you type in a expression in a property > sheet in ms-access (you have to force the expression service to take care of > this). > > so: > > Hello > or > "Hello" > > Will be taken as an literal > > To avoid confusing, I just always use the expression service in macros, and > hence: > > =("Hello") > > so, you code might go: > > SetTempvar (i,1) > > messagebox =("Value of I = " & [TempVars]![I]) > > So, it really the same as using expressions in ms-access... > > You need to put =() and you have an expression... > > Here is a screen shot of a macro that sets a value, and then runs a loop 5 > times display the value 5 times (the message box will appear 5 times). > > > http://cpedvw.bay.livefilestore.com/y1pV0NrTr6kZF89YQf6BnUUodaeTLeRvn9_znWYBrHZKr5JCUedqGnmHsCA1Dcxs4lMzlYvzeeMBDNSd5M-Ex-8OIzImfqdlmpY/macr1.png > Thank you. Your assistance is invaluable. I will play with it shortly. I'm curious about the SetTempVar (,1) line. The why 2 args? Is that due to a for/next loop structure I was looking for a For/Next loop function. Interesting to see the RepeatCount line. Hopefully it will be in Help. :) Let's say you have a Macro with Action1 Action2 Action3 You then realize you have the need to put an action between 1 and 2. Is the method to go to the buttom, do an AddNewAction, and then more it up? Or can one go to Action2 and insert it somehow? Is Macros the way to start thinking now? VBA old school, new way Macros? There being so much info in these posts, I forget...if you want to run an app on the web must you do it all via macros (because the actions one can perform on the web are defined) or can it also run VBA code in a web app as well?
From: David W. Fenton on 25 Nov 2009 17:56 Salad <oil(a)vinegar.com> wrote in news:n9qdnXxbVJtV0pDWnZ2dnUVZ_jCdnZ2d(a)earthlink.com: > Is Macros the way to start thinking now? VBA old school, new way > Macros? There being so much info in these posts, I forget...if > you want to run an app on the web must you do it all via macros > (because the actions one can perform on the web are defined) or > can it also run VBA code in a web app as well? This is the part that bothers me the most. I thought I could ignore the embedded macros in A2007, since I was never in need of the "security" level that it seemed to me they were designed to provide (i.e., a codeless Access application that wouldn't violate paranoid IT departments' policies about running VBA code), but now it's quite clear that they've been heavily leveraged. The table-level data macros are something EVERYONE is going to use, seems to me, because it means you now have TRIGGERS. That's just huge. Also, with macros now having flow control and branching (e.g., If/Then/Else), internal variables and error handling, the main deficiencies of them are no longer there. That said, I still think they are problematic from a documentation point of view. Event code attached to a control on a form is "embedded" in a certain sense, but it's easily accessible from an external source, simply by browsing in the VBE. Even before A2000 and the VBE, you could always search the whole codebase, and navigate your project via the object browser. So far as I know, there are no corresponding tools for "macro management" and navigation as you have for code management. I'm very conscious of this right now after having spent my summer on a major revision of an app that started life in Access 2 and had not a single line of VBA code (all macros). It was a real tangle and incredibly difficult to forecast what effect deleting a macro might have -- yes, I could use search and replace tools, and I certainly used them extensively, but that's not the same thing as having immediate access. Also, after the introduction of A97, I haven't used macros for anything at all other than the things that require them (AutoExec, AutoKeys, some menu-based operations, though that, too, is no longer necessary). So, I'm totally unfamiliar with the basics of how to construct them, e.g., how to force evaluation of literals in the example you provided the answer for here. Thus, there's going to be a learning curve and that's going to be quite frustrating. For new users, it's going to be very powerful and useful. But for us old hands, it's going to be quite frustrating, I fear. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Salad on 25 Nov 2009 19:11
David W. Fenton wrote: > Salad <oil(a)vinegar.com> wrote in > news:n9qdnXxbVJtV0pDWnZ2dnUVZ_jCdnZ2d(a)earthlink.com: > > >>Is Macros the way to start thinking now? VBA old school, new way >>Macros? There being so much info in these posts, I forget...if >>you want to run an app on the web must you do it all via macros >>(because the actions one can perform on the web are defined) or >>can it also run VBA code in a web app as well? > > > This is the part that bothers me the most. I thought I could ignore > the embedded macros in A2007, since I was never in need of the > "security" level that it seemed to me they were designed to provide > (i.e., a codeless Access application that wouldn't violate paranoid > IT departments' policies about running VBA code), but now it's quite > clear that they've been heavily leveraged. > > The table-level data macros are something EVERYONE is going to use, > seems to me, because it means you now have TRIGGERS. That's just > huge. > > Also, with macros now having flow control and branching (e.g., > If/Then/Else), internal variables and error handling, the main > deficiencies of them are no longer there. > > That said, I still think they are problematic from a documentation > point of view. Event code attached to a control on a form is > "embedded" in a certain sense, but it's easily accessible from an > external source, simply by browsing in the VBE. Even before A2000 > and the VBE, you could always search the whole codebase, and > navigate your project via the object browser. So far as I know, > there are no corresponding tools for "macro management" and > navigation as you have for code management. > > I'm very conscious of this right now after having spent my summer on > a major revision of an app that started life in Access 2 and had not > a single line of VBA code (all macros). It was a real tangle and > incredibly difficult to forecast what effect deleting a macro might > have -- yes, I could use search and replace tools, and I certainly > used them extensively, but that's not the same thing as having > immediate access. > > Also, after the introduction of A97, I haven't used macros for > anything at all other than the things that require them (AutoExec, > AutoKeys, some menu-based operations, though that, too, is no longer > necessary). So, I'm totally unfamiliar with the basics of how to > construct them, e.g., how to force evaluation of literals in the > example you provided the answer for here. An autoexec macro is about all I've ever used, VBA being the replacement so I know what you mean. > > Thus, there's going to be a learning curve and that's going to be > quite frustrating. For new users, it's going to be very powerful and > useful. But for us old hands, it's going to be quite frustrating, I > fear. > It will be a switch, but the gains seem to be worthwhile. |