A2010 macro builder and a message box
in [Help]
|
Prev: Help in A2010
Next: New features of Access 2010
From: Albert D. Kallal on 26 Nov 2009 02:33 "Salad" <oil(a)vinegar.com> wrote in message news:n9qdnXxbVJtV0pDWnZ2dnUVZ_jCdnZ2d(a)earthlink.com... > Albert D. Kallal wrote: > > 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 There is 2 args, the 1st one is the variable you want set, and the 2nd arg is the value. so, SetTempVar (i,1) SetTmpVar (j,2) Would set the value of temp var I = 1 And, set the value of temp var j = 2 > 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? Well, note that ctrl-up-arrow and ctrl-down arrow does move code blocks up or down (and I LOVE this feature..and wish the VBA editor could do this). However, To insert, just drag the command from the action catalog where ever you want into the code. You can also use drag and drop to move code EXISTING blocks around, and if you use ctrl+drag, you can copy code by drag + drop. I wish there was an insert key. However, if you drop in a EditReocrd, or even an if..then block, then there is a blank "add new action" that appears inside of this block. So, you can well insert into existing code "blocked" commands like editrecord or if..then. And, it turns out these are common places where you insert additional code anyway. So, you have to change your habit a bit when you want to insert a few lines of code. I find it best to just drag + drop the command from the action catalog into the middle of the code wherever you want.. > > Is Macros the way to start thinking now? VBA old school, new way Macros? No, not really, I think if you developing a desktop application, I would stick to VBA. there are two significant reasons to use macros: 1) data triggers: 2) Web applications. I really like the new table trigger feature. This gives access developer's stored procedures and triggers. This feature is something that I wish we had a long time ago. I can't tell you how these triggers start to "change" the way you approach some problems. You will learn to THINK differently about some solutions. Obviously to use these new table triggers and stored procedures in access, you'll have to adopt the data macro programming language. So, ONE great reason to learn the new macro and specifically data macros is to take advantage of these triggers. I still suggest that the overall application you build is going to be far better for you to stick to using VBA. > 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? The above question really answers the second reason why you want learn data macros. For web based forms, to make your buttons, code etc, it all must be macro code. NO VBA. In fact it's a real challenge to change designs for web based application. The reason for this is that MOST of your program logic and data processing HAS TO go into the stored table procedures. In fact, you will be in a state the shock the first time you create a web form. The lack of functions you have sends a cold chill up your back!. You really have to change how you approach your designs. I think it's GREAT that one's mind has to go through that mindset change, but it's hard when you have all this longtime habits you built up an access over the years. The long time desktop design approach in which MOST of your program logic goes inside the form has to be changed. You UI and data code has to be separated. I think it's absolutely wonderful that access gives us this new Paradyne. This forces a mentality change, and REALLY allows one to learn the web design approach. The result of this effort is a true multi tier web based application. I think the feature limitations (ie: lack of features) is the hardest part to grasp or get around when you first jump into this web thing. Access won't tell you to design this separation of user interface and code. You'll just simply be forced this way. You will find few features you need in the forms. You then must "come up" with NEW designs that work different. You will just have to stumble along and find out where the functionality is you need. The functions and features you need will be found somewhere else. A really terrific example of this, is that in one of my web forms, in the web forms on-load event I wanted to setup 4 listboxes. Here is a screen shot of that form: http://nrfu5a.bay.livefilestore.com/y1pda3NDGJUHH2-YzB0WaK4fob4_pkAbG5G_MMQgTZmnadxqtulr9cVdPSuTq1w0vu7ZkTprZRNK8deUqAiqXc1917I7A_IWkgX/Book1.png Note the 4 listboxes are simply 4 unbound listboxes that allow the user to click on time. I did this so the user does not have to jump from the mouse to the keyboard and back to the mouse. In other words, my goal was 100% mouse for this web form. I have used that type of time picker for YEARS in VBA forms. So, in the forms on-load event I wanted to do the following: lstboxStartHour = Hour(startTime) lstBoxStartMinute = Minute(StartTime) lstBoxEndHour = Hour([EndTime]) lstBoxEndMintue = Minute([EndTime]). The problem here in the web forms UI macro we don't have the Hour() etc. functions. Note the new terminology here. UI macros and data macros (for example, data macros don't have messagebox commands). Anyway, Guess what? The UI macro does NOT HAVE the hour(), minute() commands that I expected in VBA! So, now what? How do you change your design here? The simple solution was to base the form on a query. The web query builder DOES HAVE most VBA functions we come to expect. And, since the form is still editable if I base the form on a query in which several columns are function based. So, here is a screen shot of the web Query I built: http://nrfu5a.bay.livefilestore.com/y1pXFsdTOCSx319yvWwRZnVrldadpxYmYF3nRBf5Pu9b2gvor5alkSn-ycaNKkUSKez-vBFlEjPR_O4fo6ogcJI1kWD4R5SnBWv/book2.png So, now, my on-load macro code works, and looks like: http://nrfu5a.bay.livefilestore.com/y1p4oOFc8KLobCfUDaeU0rHlCz8EPlwY4nuTDdo-T65asgQhRyoHp7jE-7I1yj2JU5-WDWP892a4xb47fJTgeAY-X1eEtdj79Ib/bookMac.png Note that when the above screen shots display, I do believe clicking on the screen shot again will zoom it in further... At the end of the day, I so been able to accomplish just about anything I wanted web wise, but you have to change your approach. For example, setting up 2 cascading combo boxes takes us a few minutes. An experienced colleague of mine played around for nearly an afternoon to come up with something that worked in a web form. So, for some things, you have to prepared for workarounds. For some, this is fun, for others..it frustrating... The access web system is really quite simple, but yet is rather capable. With alpha 5, zoho, and and even FileMaker all staring to offer web stuff, then access really had no choice but to join this party or face falling behind in the marketplace... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 26 Nov 2009 16:02 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:hbqPm.37005$ky1.14891(a)newsfe14.iad: > With alpha 5, zoho, and and even FileMaker all staring to offer > web stuff, then access really had no choice but to join this party > or face falling behind in the marketplace.. Filemaker has offered it for about 5 years, so it's not just a new need. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 26 Nov 2009 16:03 "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in news:hbqPm.37005$ky1.14891(a)newsfe14.iad: > For web based forms, to make your buttons, code etc, it all must > be macro code. NO VBA. In fact it's a real challenge to change > designs for web based application. The reason for this is that > MOST of your program logic and data processing HAS TO go into the > stored table procedures. You don't have embedded macros in web forms? I can't imagine how you could put UI navigation logic into table-level data macros. Also, are shared macros available, i.e., non-embedded macros that can be called from any web form? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Albert D. Kallal on 26 Nov 2009 16:53 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote in message news:Xns9CCFA35A985C8f99a49ed1d0c49c5bbb2(a)74.209.136.82... > "Albert D. Kallal" <PleaseNOOOsPAMmkallal(a)msn.com> wrote in > news:hbqPm.37005$ky1.14891(a)newsfe14.iad: > >> For web based forms, to make your buttons, code etc, it all must >> be macro code. NO VBA. In fact it's a real challenge to change >> designs for web based application. The reason for this is that >> MOST of your program logic and data processing HAS TO go into the >> stored table procedures. > > You don't have embedded macros in web forms? I can't imagine how you > could put UI navigation logic into table-level data macros. Yes, you have embedded macros. and, you also have general web macros (that are not part of a form) that can be called by these ui macros. So, for example, in my calendar booking form, I wanted the code + form called in ONE place for the 42 text boxes "click event" that makes up the calendar. So, while I did have to code 42 embedded click events on the calendar, the code for each click event called the same one non embedded macro (so I could easily change the click even code in one place for the 42 controls). That code would simply launch the calendar details form with a date "where" clause and had a bit other code in it.. So, yes, each button and each text box control on a web form has events and you can (will) embed macro code in that form. Those embedded macros can call regular web macros (ones not part of a form). These UI macros (UI macros = terminology for forms embedded macros) can also call data macros (data macros = terminology for macro code attached to a table). UI macros can pass parameters to Data macros. Data macros have the ability to do things like recordset processing (but, they are not called record sets). > > Also, are shared macros available, i.e., non-embedded macros that > can be called from any web form? Yes, not only are there shared macros (non embedded macros), but there is as mentioned the table level macros. These table level macros can be called from table triggers, or called from UI macros. Note that code wise table trigger macros have the same feature set as table macros. And, regular web macros are feature wise quite much the same as UI macros, but they just are not embedded in the form. These UI macros and regular macros can pass parameters to these data macros. Note that client only forms can of course have VBA code, or macro code (and, client side forms macros don't have the limitations that web forms have, so client side macros very much have most vba functions for example). So, a forms UI macro can call either data macros (which are associated with a particular table). or can call macros that are NOT embedded in a form. Those non UI macros can also call the table macros (or so called data macros). Validation macro code at the table level can execute a raiseerror, (with a custom error number), and that error can be trapped by UI macros. 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.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal(a)msn.com
From: David W. Fenton on 27 Nov 2009 15:36
"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. I'd assume that a client form/report can call a web macro while a web form/report can't call a client macro? I'd also assume that table-level data macros are callable by either? Yes, no, maybe? -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |