Question

A little more than three years ago I wrote an Access db to use for our bank accounts and budgeting. I've used it and loved it ever since because it does several great things that nothing else out there does. I've decided for several reasons to write it into an independent program. I'll let some family and friends use it, and later, after tweaking it to some degree, maybe try to market it a little. I don't expect to overtake Quicken, but who knows, maybe it could turn into something.

From what I can gather, deciding the language probably needs to be done first. So I'm here to ask and get help finding the right one to use. Here are my considerations:

A) I'll definitely want an attractive looking GUI. And nothing "Windows" looking.

B) Ease of packaging for distribution, and installation, are of course very high priorities. Windows-only is fine.

C) My training/experience level: some simple VBA (what's in the Access db), recently took a non-GUI C++ class, and could take an Intro to Java class this semester if I go with Java.

D) I had thought I'd use a SQL database back-end (am I saying that right?) as a place for the data, because I have the Access db to use to model it after, and I'm familiar with a little SQL.

E) I am aware that I need to be mindful of the libraries' licenses if I want to eventually be able to sell the program.

F) For now, for sure, I'm not interested in any web-based functionality or for it to run in a browser.

To sum up, I'm a willing, barely-smart-enough, barely-capable-enough, novice with some light experience and training, who wants to write his Access db into a real program, and maybe try to sell it one day. What language should I use?

And I guess I ought to ask also, does it appear that I might be missing something important? Thanks very much.

*I know there are people who would give me advice on whether or not I should try to sell it (or even could) but that's not why I'm here, so please don't.

Was it helpful?

Solution

Given your expertise and background, VB .NET using Windows Forms for the interface would would be easiest for you to pick up and start working with. SQL Server Express or Compact edition will meet your DB needs, is similiar enough to Access that it won't feel 100% foriegn, and can easily ported to full SQL Server if you ever need something more.

I will also mention C# as a possible language. As a novice programmer with no experience outside of VBA it will be harder for you to pick up, but there is a LOT more community support, technical books, and free source code available in C#.

I really like WPF for developing user interfaces, but the learning curve is very steep. It is not for novices at this time.

Win Forms has terrific, easy to use, tools for building the most common types of interfaces, and will be similiar enough to the form designer in Access that you will be able to get going quickly.

Spend extra time in your design phase to make the business logic as seperated from the presentation logic, that way you may be able to replace Win Forms with something snazzier later.

Here is a link to the official site for learning about Windows Forms and WPF. There are lots of videos and exercises and other materials for new developers. Spend a little time everyday studying some of the material there and you'll pick up a lot. Microsoft has similiar sites for other technologies as well, such as SQL Server, ASP, and so forth.

Make sure you have a decent source control solution. It will save you on more than one occasion. If you can't afford your own, or don't want to go to the hassle of setting up and maintaining one, there are places online like CodePlex that will provide source control for free if you make your project open source.

Good luck with your project.

OTHER TIPS

Given your Access experience and the requirements you've listed, I would suggest .NET for a platform, VB for a language, WPF as an UI framework, and raw ADO.NET (+ possibly datasets) for database backend. You might also want to try LINQ to SQL and see if it makes sense to you, but you will probably find plain ADO.NET more familiar.

EDIT

I've missed the part of the question about database. For the task you describe, consider the free SQL Server Compact Edition. It's in-process, just like Access, and so there is no hassle deploying the service etc, that you get with SQL Express. Other free server-less DB options are SQLite and Firebird/Embedded.

Regarding deployment - for a simple application (that needs just copying .exe and .dll files over and creating the shortcuts), .NET Setup project will probably be sufficient, and is very easy to create.

I see you saying two contradictory things:

nothing "Windows" looking.

Windows-only is fine.

You should strive to make your application look and feel like any Windows application, especially if OS-independence is not a concern. One of the fundamentals of human-computer interaction is that consistency reduces the amount of time it takes for new users to learn the application you have written.

If it looks like every other application, has the same icons in roughly the same place, with the same boundaries and colours as other applications, you're taking advantage of the fact that users already know all of these things. If you specifically skin your application and use non-standard icons, colours or even metaphors, users are going to have to learn the new theme as well as all of the functionality the application offers.

It would be better if you wrote your application to be skinnable, and have it default to the regular Windows look and feel, so that users can learn its functionality without learning a new look and feel. Then, once they understand the app they can switch to the skinned mode to learn that independently of the functionality.

I would suggest QT 4.5 from TrollTech/Noika

A) QT Windows can be skinned

B) I am not so clear about how QT can be distributed (yet), but one thing is that it is cross-platform

C) I find coding GUI in QT straightforward and is not as contrived as MFC; the tutorials there are good enough to get started with.

D) QT has SQLlite (allowing you to have a database without the need of a server) and has packages for interfacing with SQL databases, but I am not sure about Access

E) After merging with Nikola, QT 4.5 is now LGPL, so as long as you link to the library, you shouldn't have issues with distributing your software. Changes made to the QT 4.5 files have to be released, as per LGPL.

Another point - QT 4.5 has a robust view/scene architecture for graphical programs and the signal/slot mechanism makes coding GUI and linking their changes to their data class much easier than MFC or even with delegates in C# WinForms.

Python

  • Since it's quite unlikely you will ever encounter data volumes where it makes a difference (and if so, I/O, not code is probably the bottleneck.) you should get a language that is as pleasant to develop in as possible.
  • Python has nice, standardized db libs, start with sqlite3, since the db just lives in a file. If you need to, you can swap it for an oracle db later.
  • It also has a number of GUI options, so having the discipline to keep the GUI separate is easier. (you should anyway, but...)
  • Very good multiplatform support, even some of the GUI alternatives manage this. (Some better than others, though)

Python is also friendly, in that doing the wrong thing feels wrong, and doing the right thing feels right. I can't even begin to explain the wonders of that feature.

I suggest that you write your application as a web application using macromedia flash for the front end and java for the back end. Hear me out.

A). Flash has a very rich library of slick looking ui widgets. Designing the look and feel of a flash ui as easy as click and drag. Very illustrator like.

B). Out of the box flash is cross platform, works all on versions of windows. You also get osX, linux and soon mobile device users. No need to worry about security permissions, corrupt installs, or weird dlls. Plus, if you need to release a patch, you update the flash app on your web server and all the users get the new version next time they use it. You don't need to worry about packaging or shipping.

C). The future software is likely to be more and more web centric. While web applications may not replace all applications, certainly they will replace most. Growing these skills now is important.

D). Yeah, sql is an improvement over access. There is a lot of sql know-how out there, SQL is a good choice.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top