calling functions for repetition

[neuroman9999]

guys,

has anyone designed an app in access that literally did the same thing over and over again? if so, how did you use functions that were to be called a million times with different args each time? here's an example:

public function dataEntered(ctrls() as string, frm as string) as boolean

dim i as long
   for i = lbound(ctrls) to ubound(ctrls)
      if isnull(forms(frm).controls(ctrls(i))) then 'required field not filled in.  throw error
         dataEntered = false
         exit function
      end if
   next i

dataEntered = true

end function

and then of course, behind any given form's "save record" button, would be something like this:

private sub btnSave_click()
dim arr() as string
dim c as control
dim i as long

i = 0
   for each c in me.controls
      if typeof c is textbox then
         if i = 0 then
            redim arr(i)
            arr(i) = c.name
         else
            redim preserve arr(i)
            arr(i) = c.name
         end if
            i = i+1
      end if
   next c
if dataEntered(arr(), me.name) then
   docmd.runcommand(accmdsaverecord)
   msgbox "Record has been saved!",vbinformation,"Confirm"
   docmd.gotorecord acnew
else
   msgbox "All fields are required to be filled in!", vbcritical, "Error"
end if

I realize there is redundancy in that code, but the idea is there. is that the way all you guys do it? if of course, you get to do what you want to do as pros, and not just throw crap together because management has no idea what they're doing and/or their customers are nuts and change their mind 24/7?

 

[Pat Hartman]

You already posted this question in a different forum.

 

[neuroman9999]

You already posted this question in a different forum.

this is a different issue. it's about programming philosophy. did you catch that part?

 

[The_Doc_Man]

I'll actually take a shot at this one. I believe my answer will be relevant to the specific question that was asked.

What I did for my biggest project was I looked hard at how many forms I was going to need to do table maintenance functions in a controlled and consistent way. So I created a template form that had pre-defined buttons for things like COMMIT (meaning SAVE), UNDO, CREATE, REMOVE (meaning DELETE), and a couple of secondary functions like FILE TR (meaning file a trouble report) and HELP (which launched a context-sensitive help facility based on a Word document with a LOT of bookmarks.) The form also had pre-defined calls to some code that adjusted control color schemes based on being dirty or being "virgin" (part of a new record) and some other states. It filled in the user's name and role in a fixed area on the form and had definitions of user roles and privileges already there to be used to decide on-the-fly just what the user could do and see. Logging was also built-in But the template had no declared .Recordsource or data-type controls.

Then when I wanted to make a new form, I copied the template and customized it. Depending on the complexity of the table, I figure I saved anywhere from 40% to 50% of coding that would have been repetitious. Since I had a lot of translation tables to manage, I ended up with over 20 forms to maintain tables. I recall that I only had maybe 2 or 3 forms that just didn't fit the mold very well, but even for those I could use a cut-down template that did read-only stuff.

So TECHNICALLY I used code that got repeated a lot. But I actually only wrote that code once and stuck it in the template then just did copy/paste/rename/customize and I was in business. I think this is responsive to your philosopy question, Adam.

A side-effect of doing it this way was "consistency of look-and-feel." It was clear that every form was part of the same product. If you knew how to use form A on software, you could use form B on computers and form C on security notices because they all behaved alike. This is not a trivial goal.

 

[neuroman9999]

I'll actually take a shot at this one. I believe my answer will be relevant to the specific question that was asked.

why do you doubt yourself!? I wanted you to answer, as you are the veteran here. Didn't you know what I was doing!? No one is a better teacher than you here, (most of the time. )

So I created a template form that had pre-defined buttons for things like COMMIT (meaning SAVE), UNDO, CREATE, REMOVE (meaning DELETE), and a couple of secondary functions like FILE TR (meaning file a trouble report) and HELP (which launched a context-sensitive help facility based on a Word document with a LOT of bookmarks.)

I'm pretty sure that this way of doing things will become the way of future, specifically because the corporate world will force logic and "step-by-step" behavior on the rest of the world. it's a huge selling point. and people will literally eat it up without fighting. that's the way it always works. they get tired and do what the corps want eventually. the question mark is, what comes after THIS? if the computer controls your entire life, what else can be sold to you!? but on a side note, I think this is kind of the way Oracle has done forms since they became incorporated. They use huge amounts of forms, one on top of the other, time and time again. Last time I used Oracle software, the form count was so large, I almost got lost in the stack!

I think this is responsive to your philosopy question, Adam.

of course it is, and I will use all the info you gave. thanks.

 

[The_Doc_Man]

It has been a while since I got very close to ORACLE Forms because that was another department. My system used ORACLE but wasn't web-oriented. So the only time I saw ORACLE Forms was in the fiasco that was DIMHRS. And ORACLE Forms lost to PeopleSoft in that case. Made me want to puke because I knew then and there that the project was doomed. And it was. But I have described that elsewhere and I count it as a bad memory I wish I could forget.

 

[neuroman9999]

oh dude, Peoplesoft sucks. seriously. and yes, apparently your reference was a pretty big failure:

Defense Integrated Military Human Resources System - Wikipedia

en.wikipedia.org

 

[neuroman9999]

by the way, @The_Doc_Man , have you ever SEEN anything or even used anything produced in the .NET framework? I have yet to look at the MVC (model view controller) architecture, however it is all the rage right now. and it can be produced in any language. there are templates that have this layout, written in all languages, and I do not understand what the obsession is. However, what we can always count on, is if any single company in the world starts to profit from a trend, every other damn company will jump on board immediately and imitate.

this whole MVC trend is just as stupid as google and facebook creating new JS frameworks and calling them BRAND NEW and ''innovative''.

 

[The_Doc_Man]

No, have not gone that way. Don't know much about it.

 

[neuroman9999]

You see Richard this pretty much confirms my assumptions about the model view controller layout. take a look at this article even though I know you guys say Wikipedia can't be trusted but nonetheless it's okay for informational purposes. This just goes to show you that the MVC concept is nothing more than a non-innovative attempt by the corporate world to make money and pawn it off as innovation. What's so innovative about a brand new interface with new buttons on it?

Model–view–controller - Wikipedia

en.m.wikipedia.org

 

[The_Doc_Man]

In the past I have implemented variants of this model, split across at least six functional elements. I cannot tell you why people like model A this year and model B next year. Perhaps it is because they have tried to implement something with model A, failed miserably, and blamed it on the model rather than the specific/detailed design or the implementation team.

There is nothing inherently wrong with the model, it is just one of many ways to look at a problem. If you looked at that article closely enough, you would have noticed some other models that one could use as the basis for an app structure.

 

[neuroman9999]

There is nothing inherently wrong with the model, it is just one of many ways to look at a problem. If you looked at that article closely enough, you would have noticed some other models that one could use as the basis for an app structure.

I was addressing innovation. there is nothing innovative about new designs in the software realm. that is all about user experience. that is completely devoid of transformational necessity. the truely innovative minds of the world are thinking the latter, not the former. the reason the former is being called innovative and looked at as such, is because the corporate morons are still selling to 3rd world countries that house people who don't know their left hand from their right hand, and thus they have no clue what innovation truly is. thus, they will buy anything if they're convinced that IT IS NEW. like I've said before: js extensions. that's NOT. google and facebook leaders just say it is. that's not impressive.

 

[Pat Hartman]

Some people are transfixed by shiny, new things. Others prefer to spend their time implementing solutions they know will work. It is the difference between R&D and production. Are you being paid to come up with some new and hopefully better way of doing something or are you being paid to actually do something? Somehow, I don't think the world is better because there are fourteen different plugs to connect your phone, laptop, notepad, etc with a power source. The world would be simpler and more convenient if the shape matched the power required so you can't plug a device into the wrong power source. That would be innovative engineering. I once had a stand mixer where the plug ends of the beaters were different and the a beater needed to be inserted into the A slot and the b beater needed to be inserted into the B slot. However, because the engineer didn't bother to make the a not fit the B slot and the b not fit the A slot, my friend who didn't know the drill got the beaters in backwards and completely covered my kitchen and us in whipping cream. It was hysterically funny if you're into slapstick but I was still finding tiny hardened beads of cream months later.