This post will show my attempt at doing a navigation bar
with the ExpenseIt non WPF (Windows Presentation Foundation) application example
of Microsoft as I implemented using only Windows Forms and C# with the
Microsoft Access database provided to avoid the need for canned data. (See the previous post “C# Displays Follow
On for ExpenseIt Using Access Database” for the basic structure of the application
that is being modified with its various Windows forms.)
Leaping into the task of implementing the navigation arrow
buttons, as I have been prone to do of late since coding is so easy – just add
code, compile, correct errors, compile again, etc – I have gotten out of the
habit of thinking things through first.
So I had a couple of false starts and also ended up with excessive
code. In addition I had a couple of
lapses.
The first dope slap was when I switched from my usual “list”
construct that is a replacement for a queue to a circular queue to maintain the
form selections. I had been mystified
by the other Windows Forms not being able to access the selections pushed onto
queue by the Menu form. Then, of a sudden,
it dawned on me. I had created new
instances of the database classes for access by each of the “worker” forms and
so had done so for the circular queue as well.
But the insight came to me that the reason these forms couldn’t read the
previous menu selections was because the forms had their own versions of the
queue. That this didn’t matter for the
database classes since the data was stored in the Access database tables and
not in the C# class. But that that this
wasn’t the case for the circular queue where it stored the data so a new instance
of the class meant an empty queue. So I
needed to pass the instance of the queue of Form1 – the Menu form – to the
other forms as Form1 instantiated them.
In the end I didn’t use the circular queue anyway since I
hadn’t thought through how I was going to access it to obtain what the next
left or right form selection might be.
When I realized it wasn’t quite as simple as I had assumed and actually
made samples of what would go into the queue I replaced the code of the
SelectionQueue class that I had created to return to a simple array once
more. That is, a version of my usual
list construct for a queue. And even
simpler since there would be no need to “pop” the queue – the array was never
going to get very long since there would only be a maximum of five
entries. But the need to pass the Form1
(master form) instantiation of the class to the other forms was a lesson
learned.
So I implemented the arrow buttons and changed the displayed
forms, hiding the currently displayed form and showing the newly selected
form. As I proceeded I came to realize
that I had an excess of repeated code.
That is, since each form had its own pair of arrow buttons, each had its
own pair of button click event handlers.
So each came to have its own repeated code to determine what the
navigation arrow had selected.
Therefore, a need to consolidate into, perhaps, a new Navigation class
to contain the code to implement the button event.
This got be to thinking (for a change) and I thought about
the navigation bar of web displays and also of such things as the tool bars
that get added to forms. It seemed to
me that there needed to be a super form so that the Navigation Bar could be
part of it along with the form title and the minimize, maximize, and terminate
buttons of the upper right corner. So,
whether there was an option that could be used to overlay another form below
the upper portion that would display a boundary but not a title and the upper
right buttons.
Then the navigation arrows would be in the super form and
not the individual forms so there would only be one set of mouse click event
methods. Or, lacking that, even with
multiple mouse click event methods, they could all be treated by the same
instance of a navigation class rather than having separate code in each of my
forms. (This preceded the completion of
the code by half a day and finding that each arrow click event handler had the
same code as mentioned in the paragraph above).
Then it occurred to me that I could treat a panel like a
form. That is, have one form rather
than four with the panel of the arrow buttons and a lower set of panels for
what I am now treating as individual forms.
Instead I could have multiple lower panels and change which lower panels
are hidden and which is displayed when the Menu panel selections are made or
the arrow buttons of the upper panel are clicked.
This seems like a very possible course of action and
something I should do next. Although it
takes me away from finding out about support for Windows threads vs Threading
threads that I had a problem with when I tried to combine my framework with
Windows Forms. Then it occurred to me
that I likely did such panels in the C# Display application that I did years
ago that interfaced with the Ada framework applications. Creeping into my consciousness is the thought
that I did. And that I have gotten into
a mode of action first without much thought about my approach since so easy to
code now and change later (as I mentioned above). An UltraEdit search of the folders used for those applications
shows that I did indeed use panels.
Since the code is currently rather ugly and will be replaced
by using only one Windows form and multiple panels I will not present it
here. Instead here are the pages
showing the navigation arrow keys after the menu selections were made to show
the Add Employees, Update Employees, Enter Expenses, and Display Expenses.
Because of the order of selection, there is no selection to
the left of the Menu and none to the right of Display Expenses. Note: As presented in the previous post,
these last two Menu selections both display a list of employees for a choice of
the employee for which the expenses are to be entered or displayed. So both appear the same except there is no
right arrow for the Display of the employees Expenses.
No comments:
Post a Comment