Late Control binding to make Forms Field independant. (3 Viewers)

[isladogs]

OK thanks. My email address is below.
All being well, I'll post the file back in the thread as a 64-bit ACCDE

 

[tvanstiphout]

I use only TextBoxes.

That is the biggest rub for me so far.
It leads to more clicks and more forms popping up to get things done. For many of my customers high-speed data entry is very important.
Plus, the aesthetics of it: no dropdowns, no checkboxes, no radio button groups etc. I know beauty is in the eye of the beholder. All those purpose-built controls that we see in every other app are swept aside for what? The choice of one developer, and in service of the bigger goal of reusability?

I'd like to be blown away by what this approach makes possible, and I'm sorry, but I will watch from the fence from now on.

 

[Edgar_]

@Imb
I just tested the sample file and I couldn't make it work. I put all files in the same folder and then a form with a message appeared. After discarding the form with the message, another form opened with 3 buttons. Clicking on them returns error 3043.

A few thoughts about the situation:
1. You've said it's quick to develop with it, but it remains a mystery how that is done.
2. There is a language barrier to overcome because some things are in english but a lot of others are not
3. I could attempt to fix it, but since the project is locked, I can't and shouldn't if I tried to unlock it

 

[The_Doc_Man]

Since you cannot design forms your way by referencing the traditional Microsoft Learn library, I hope you wrote up some good documentation.

@Imb

Given Tom's and Edgar_'s responses, I return to my original comment. Take this as an attempt to give constructive criticism as I offer you a direction I think you need to go to improve your presentation. If you have inadequate documentation, your product is generally useless to anyone but yourself because from the limited sample of some pretty high-powered guys who tested this sample, you are the only one who can make it work.

 

[Albert D. Kallal]

@Albert D. Kallal,

Thank you for your reply.
Your definition of a re-usable control is completely different from mine.

Yes, it is differrent. Keep in mind, that you suggesting benefits arise that the form now does not have that binding information.

However, all you done is move that developer workload to another location - you STILL have to do that work!

Remember, I do a LOT of web development work now, so I well grasp the concept of separating UI code from business logic code.

Asp.net "MVC" is a perfect example of this approach.
(Model-View-Controller).

MVC is a design pattern used to separate concerns in web applications by decoupling the user interface (view), data (model), and application logic (controller). This pattern helps in organizing code in a more maintainable and testable way.

However, you at the end of the day simply shuffling the developer workload from one location (in the form) to another location, not that you eliminate having to do this!

So, while there are benefits to moving as much code and logic out of the UI? There are also MANY benefits to do so!!!!

In the Enter event of that control it is told how this control must behave, that is the binding to Fields and Business rules. My interpretation of re-usable controls.

Sure, but you still having to outline and define that binding process - it's still being done, just not in the form anymore. So, the question then becomes how great are the benefits vs the downsides of this approach?

As noted, right now, since we "often" have to move some code and forms from the internal Access application to that of the customer facing web portal? (a great recent example is after a customer has approved a project, then we present them with the shipping page - and they can edit the shipping address, select other locations they have, and also enter comments). And same goes for approval process - used to be 1000+ lines of VBA code. That code still exists, but now both web site, and VBA/Access desktop uses the .net business object for that code. Hence, one code based is shared between the web site, and the Access desktop. And over time, we are moving more and move VBA code into that business object.

However, at the end of the day, mapping of data from that business object to the UI? We still have to do that work load. The fact that we moved boatloads of code out of our Access forms, and even data binding code out (say for web forms doing the same thing)?

The UI presentation is not just UI, but the UI has to behave in many special ways to achieve a desired result. In other words, the UI is NOT limited to JUST data binding (or removing that data binding), but has to do much more to create a great user experience.

This goes all the way back to people often suggesting that you can build a application using just wizards and have the UI work like magic.

No, you actually can't!!!

The REAL value of such systems is in fact attaching that business logic to that UI interface.

The fact that the business logic is moved out of the form? Don't matter in the sense that such code and UI mapping STILL is required - even if you move it someplace else.

The problem more often then not?

It not that you need or "can" re-use some form (and it's controls - that tends to be easy!).
However, to make great software, that UI will require special love and care. It's never really about some text box that is "bound" or not at design time, but building a UI that allows the end user to do their job. Attempts to eliminate this task don't work, and even .net MVC does not eliminate this issue.

Editing and binding data? Gee, that's not the bulk of application development since that's oh so easy anyway!
(however, you would be shocked in web land as to how people are still hand coding the loading of data from that class, or data source, and manually writing code (hand coding) to shuffle the data columns into that UI - we don't do that in Access, and I don't even do that for my web based software anymore ....

But, just a "shuffle" of data to/from the UI? That's not the hard part, and that's not the high value part that takes effort. That part of the development cycle is REALLY fast - even using bound forms. So, eliminating this task, or even automating it somewhat?

That's not where the developer costs are these days.....

I'll certainly give the sample a try in the next while -- and I appreciate you sharing these ideas here...
So, the concepts of moving as much out of a form? Sure, they are great concepts, but, it's not a 0 or 1 narrative either way on this issue, there are benefits of both approaches....

R
Albert