4

I am using ms-access for developing front-end solutions for database management. I must admit that ms-access VBA is a solid limitation to the development of large-scale apps, and this is why I have been turning around the idea of using c# instead of VBA.

In fact, it's quite easy to get rid of everything in ms-access, except one stuff: the forms. These are particularly quick and efficient when it comes to data display and edit. In the latest versions of ms-access, forms act like classes, so you can specifically manage one or multiple instances of the same form at runtime. When used in continuous mode, they can be used to manipulate data "the excel way", with lines and columns display, filtering and ordering possibilities. In short, I like it.

It would be of course possible to reverse-engineer this form object under c# (or another similar language), but this might have already been done: have you ever used a library, an activeX control or any other kind of add-on that offered the possibility to manipulate msacces-like forms in c#?

EDIT: following Renaud's comment, I do admit there is no interest in converting only the layout part of a form, and there is no way to convert its customized/VBA part. In our specific situation, we stopped using customized VBA code in forms a long time ago, and forms properties, methods and events are managed from modules. This has even been discussed here.

In fact, all our forms rely on a common template and are automatically built out of a 'forms' and a 'controls' table. All underlying event-management code production is automated: depending on their type, controls are associated with selected events, and the event's code gives hand to standard\generic procedures held in the app's modules. This is what makes me think it is possible to transfer our 'ms-access forms technology' to a .NET platform.

Community
  • 1
  • 1
Philippe Grondier
  • 10,900
  • 3
  • 33
  • 72
  • 1
    WinForms forms are classes too. They are all derived from `System.Windows.Forms.Form` - so I'm not sure how that's any different. As far as the second half of your question goes - maybe you're looking for something like the DataBinding support in WinForms? – Steve Mar 30 '13 at 19:12
  • 2
    You'd probably want to use a third-party UI library for WinForms, looking at their data grid and editor widgets. There are only a handful of major players in the WinForms controls market. Not that some of the minor players don't have good widgets. DevExpress, Telerik, ComponentOne, Infragistics come to mind. – Tim Mar 30 '13 at 19:15
  • 1
    **IF you care about look and feel, customizability and scalability**, and cannot afford something like DevExpress (which costs U$S900 / U$S1400 depending on the package), you should consider WPF instead of winforms. winforms controls require horrible hacks (owner draw and stuff like that) to customize their appearance, and vanilla winforms looks like windows 95. Just search `"WPF application"` in google images and see it for yourself. Admittedly, WPF has a much steeper learning curve than winforms, but the long term gain is HUGE. – Federico Berasategui Mar 30 '13 at 22:51
  • 1
    ... And you would also be moving to `current` technology, not some random pseudo-deprecated dinosaur that is unable to cope with today's UI expectations (winforms hasn't had updates since .Net 2.0). – Federico Berasategui Mar 30 '13 at 22:55
  • I was responding to the OP's desire for MS-Access-like behavior. Not sure what `pseudo-deprecated` means? Soon to be deprecated? – Tim Mar 30 '13 at 23:04
  • @Tim Microsoft hasn't put any effort into winforms since 2005 (.NetFX 2.0), they're now pushing their WinRT runtime, which has a UI framework really similar (XAML-Based, MVVM-capable) to WPF. I don't think it's worth investing any time in learning winforms now. The DataBinding capabilities of XAML-based technologies are far superior than winforms, and there are [lots of things](http://stackoverflow.com/questions/15532639/complex-ui-inside-listboxitem) that are difficult or impossible in winforms, which can be achieved easily in these technologies – Federico Berasategui Mar 31 '13 at 00:24

1 Answers1

6

I am not aware of any project that would let you take an Access application and reconstruct it in .Net or anything else. I believe that there are some good reasons why such tools can only be very limited in what they offer.

A tool that would only converts the form's layout is going to be vastly lacking in purpose: it's very easy to (re-)create functional layouts manually in .Net, be it WinForms or WPF.
It can take a few hours per screen, but it's fast enough to be feasible.

An automated tool would have a hard time translating Access forms to look good in .Net though:
a lot of Access apps are poorly designed in term of UI, with poor choice of control placement, reliance on custom colour schemes and tricks to bend the limited access controls to one's will.
On top of that, you have a lot of object properties that are very specific to Access and would not translate well into .Net without requiring a fair amount of additional supporting code.

But I think the elephant in the room is VBA: most complex Access forms are customized with VBA controlling the UI and Business logic, and that can't be translated into .Net without some significant efforts.
The fact that MS Access apps are built around a procedural, module-centric approach rather than object oriented, and that Access apps invariably have very poor separation of UI and Business logic, doesn't help the cause.
Direct translation -if it was possible at all- would just create a crappy .Net application.

There are frameworks for building simple/complex business apps that are similar to Access in many ways.

Developer Express have eXpressApp Framework which allows you to build and customize UI, generating the database, manage users, security, etc and will easily allow you to construct data views with close to no code (you can add as much code as you need though, it's all .Net). The UI uses their excellent controls, which are far superior in terms of behaviour and being customizable than those in Access.
That framework targets both desktop and web (you make a single project and you get both automatically). Alas, it's not really cheap you must have a Universal Subscription that costs $2200 at this date (yearly renewal is $800).

Another product, free or cheap, depending on your MSDN subscription, is LightSwitch.
LightSwitch is being viewed by some as a modern, developer-centric- successor of Access. It was originally targeting Silverlight for easy deployment in the enterprise, but recent versions are also targeting HTML5, so you can 'run your app anywhere', even tablets.
The principle here is to easily construct decent data-oriented forms and views that allow fast data entry and customized reports.

Like you, I regularly think about how existing MS Access apps could be converted into .Net, but the more I think about the details, the hairier it gets, and then you look at what people have been doing with Access, and you know that for any tool to be successful, it would have to handle all the horrible ways that office users have constructed their apps, and that's just insane.
There are just too many ways to build an Access application, and most of them are very poor and have no chance of allowing an easy conversion without changing paradigm completely, usually forcing a complete rewrite.

Renaud Bompuis
  • 16,596
  • 4
  • 56
  • 86
  • Thanks for your time and your proposal. Indeed there is no interest in converting only the layout part of a form, and there is no way to convert its customized/VBA part. I forgot to say that I stopped using customized VBA code in forms a long time ago, and forms properties, methods and events are managed from modules. Please check my edit. – Philippe Grondier Mar 31 '13 at 11:49
  • I read the lightswitch white paper, and it indeed sounds very close to a successor to ms-access. I guess I will spend the next 30 hours giving it a try ... Thanks for showing me this trail. – Philippe Grondier Mar 31 '13 at 12:23
  • it seems that LightSwitch is ZEE thing I was looking for! Thanks. – Philippe Grondier Mar 31 '13 at 22:45
  • Access forms tend to be more consistent when compared to c#/vb.net. Forms with record navigation use built in filter box and nav buttons (go first, go last, go new). The result is 100% SAME for each form since options are built into the navigation bar. Same for use of custom ribbons which allow re-use of edit/cut paste, print and record option groups are 100% same in each form. Access tends to be more consistent since users rely on built-in features as compared to c# or vb.net where such layout consistency is not enforced. LACK of choices in Access results in a far more consistent layout. – Albert D. Kallal Mar 31 '13 at 23:57
  • 1
    @AlbertD.Kallal I agree Albert, but the question here isn't that MSAccess forms are more consistent than .Net Winforms, it's that converting Access forms to Winforms is a challenge because Access forms are different enough and customizable enough that they pose a fair challenge that no-one (unless I'm wrong of course) as really tempted to tackle successfully. When you look at controls, especially data binding, their behaviour is quite different in Access and Winforms. To make a converted form functional would require *a lot* more than just placing the controls in the right place. – Renaud Bompuis Apr 01 '13 at 00:35
  • I think it might be more to the point (for me anyway) of "get the controls onto a form", "set the right databinding for them" (where possible), "tell me what you DIDN'T do". After all, when you get to a hundred+ forms "a few hours" becomes a large $ amount, anything you can do to reduce it is worth while. and the UI might look "crappy", but it should be similar to what they were using previously, which is a start. – Roger Willcocks Jul 11 '16 at 21:00