Switching from ms-access client interface to executable file

Question

Are there any object similar to ms-access forms in VB, .NET or other microsoft technologies?

We have been now using Access for developping client interfaces with some success for the last 2 years. We are using a serie of development tools making the best use of a metamodel (we have tables for forms, local queries, menus, controls, connections, etc) and sticking to some strong programming techniques where, for example, all visual basic code is located either in modules or class modules.

Thus, VB Code held in forms has been made standard and its production is totally automated, adding predefined events to controls depending on their types (this has already been briefly exposed here).

With the exception of these forms, all the other objects we use can be in a way or another taken out of Access/mdb files: local tables can be saved as xml files, modules can be exported as visual basic files/rewritten in another language. We do not use any macro (except the 'autoexec' one), reports (we use a Crystal Reports add-in), or queries (stored in a 'queries' table)

Finding a similar "forms" object in another technology would then give us the possibility to distribute stand-alone/.exe runtime files instead of our current combination of an .mdb file and the ms-access runtime.

Answer 1

I presume I'm misunderstanding the question, but it seems to me like you are asking about WinForms and/or WPF. The basic .NET Windows client forms.

This would be the place to start.

http://windowsclient.net/getstarted/

As far as which one to use, I'm not real clear myself. So I asked

http://stackoverflow.com/questions/388711/when-is-winforms-the-correct-choice-vs-wpf

Answer 2

To my view, the main answer has to be regular windows forms, or if you prefer (and to be up-to-date) WPF. Both have good support for data-binding etc, however, neither are directly comparable to ms-access forms. And such forms cannot be stored in isolation, but only really exist as part of an assembly. Well, WPF can exist a bit more standalone as xaml, but even then there is almost always plenty of code-behind (that is part of the assembly, not detachable).

Answer 3

You will find that you need to re-code those forms no matter what you do as no other application has the same architecture as MS Access. WinForms in VB.NET are not really the same, and have several gotchas for experienced MS Access developers.

You might actually find that the best idea is to go for something like WPF, simply because it is so different that it may helps your developers focus on what they need to do, rather than trying to port over logic.

It is unclear what business logic would reside in those forms anyway. They should be simple front-end validation code, with at worst some data-binding and event-handling.Do you still need to be able to automate your forms based on your tables? In that case some form of code generator would help (although this is not a great GUI design strategy to use).