VB.Net 2.0 Checkbook Register?
-
I want to program a checkbook register in VB.Net 2.0 (on XP, not Vista). I have a couple of ideas on how to store the data. But I'm stuck at even how to begin representing the register on the screen. Can anyone give me some hints, tips, ideas in that regard? Thanks, Owen
-
I want to program a checkbook register in VB.Net 2.0 (on XP, not Vista). I have a couple of ideas on how to store the data. But I'm stuck at even how to begin representing the register on the screen. Can anyone give me some hints, tips, ideas in that regard? Thanks, Owen
Worry about how you're going to represent the data first. Answer the basic questions first. What transactions are you going to handle? What is the information needed to perform each transaction? Stuff like that. It'll make your data layer much easier to write if you lay everything out ahead of time. Basically, you want this data layer to be able to do anything you want to the data, without any kind of a user interface. How the transactions are setup and executed is the domain of the business layer. It sits between your UI and data layers and enforces all the rules for each transaction. Data is validated and massaged on this layer before any kind of transaction is built and executed by your data layer. Now, after those two are done, the user interface practically writes itself. You start with a simple interface and build it up from there. Maybe using some textboxes and buttons. Simple. Then when your ready to move up to more complex, custom drawn interface elements, like filling in an actual image of a check, you just have to modify the UI layer. I've got an "application" written entirely in SQL Server, a small football pool. It doesn't have any user interface at all but runs entirely inside SQL Server. The business logic (transactions) and data layers have been combined enitrely into SQL stored procedures, Views, and Triggers. The entire data model is defined inside the SQL database. You can run the app entirely using nothing but simple SQL statements, or, if you wanted just opening the tables and start editing them directly, like adding players, games, changing the scoring model, whatever... You can view current standings or any game details by just opening the View you want. You can't screw up the database with invalid data because the validation rules in the business logic inside the SP's and Triggers won't let you. The database defends itself from bad data entirely on its own. It doesn't need a seperate business layer written in .NET code to keep the data safe. Now, all I have to do is put together a number of user interfaces for the app, like an ASP.NET application and/or a Windows Forms app. Why did I say all this?? Because if you need to change how the application looks, you don't have to touch the business and data layers at all. The application can still run, even if you chose to use a simple console app as the user interface! Want to run this in a web browser? No problem! Just add an ASP.NET project to the solution and you can start building a web-based
-
Worry about how you're going to represent the data first. Answer the basic questions first. What transactions are you going to handle? What is the information needed to perform each transaction? Stuff like that. It'll make your data layer much easier to write if you lay everything out ahead of time. Basically, you want this data layer to be able to do anything you want to the data, without any kind of a user interface. How the transactions are setup and executed is the domain of the business layer. It sits between your UI and data layers and enforces all the rules for each transaction. Data is validated and massaged on this layer before any kind of transaction is built and executed by your data layer. Now, after those two are done, the user interface practically writes itself. You start with a simple interface and build it up from there. Maybe using some textboxes and buttons. Simple. Then when your ready to move up to more complex, custom drawn interface elements, like filling in an actual image of a check, you just have to modify the UI layer. I've got an "application" written entirely in SQL Server, a small football pool. It doesn't have any user interface at all but runs entirely inside SQL Server. The business logic (transactions) and data layers have been combined enitrely into SQL stored procedures, Views, and Triggers. The entire data model is defined inside the SQL database. You can run the app entirely using nothing but simple SQL statements, or, if you wanted just opening the tables and start editing them directly, like adding players, games, changing the scoring model, whatever... You can view current standings or any game details by just opening the View you want. You can't screw up the database with invalid data because the validation rules in the business logic inside the SP's and Triggers won't let you. The database defends itself from bad data entirely on its own. It doesn't need a seperate business layer written in .NET code to keep the data safe. Now, all I have to do is put together a number of user interfaces for the app, like an ASP.NET application and/or a Windows Forms app. Why did I say all this?? Because if you need to change how the application looks, you don't have to touch the business and data layers at all. The application can still run, even if you chose to use a simple console app as the user interface! Want to run this in a web browser? No problem! Just add an ASP.NET project to the solution and you can start building a web-based
Exactly. The data representation has very little, if any, effect on the UI. For a start, I'd like to figure out how to display a column of numbers with their descriptions in something that looks like either a checkbook register or a ledger book page -- the UI will not be adding or subtracting, just showing the data. (When I say "looks like", I don't mean it looks like someone wrote in the entries by hand: I mean that the display has columns and rows and the background color is a light green.). Thanks, Owen
-
Exactly. The data representation has very little, if any, effect on the UI. For a start, I'd like to figure out how to display a column of numbers with their descriptions in something that looks like either a checkbook register or a ledger book page -- the UI will not be adding or subtracting, just showing the data. (When I say "looks like", I don't mean it looks like someone wrote in the entries by hand: I mean that the display has columns and rows and the background color is a light green.). Thanks, Owen
DataGridView would do this easily. If you wanted colored alternating rows, that'd take a bit more work.
Dave Kreskowiak Microsoft MVP - Visual Basic
-
DataGridView would do this easily. If you wanted colored alternating rows, that'd take a bit more work.
Dave Kreskowiak Microsoft MVP - Visual Basic