Another development philosophy question - Managing two active tables in one form 1

[Scott24x7]

Hi All,
I've been working on an administrative feature for our enterprise application (which has been a long time coming) to manage our expenses (rather than using Excel as we have for the past 3 years).

The problem I am having trouble with is there are two main tables: Expense and Expense Detail. The idea is, you have 1 expense record with many expense details. I usually have a set of controls on the form for add, edit, save, delete, cancel, etc. But since I have two active tables on the same form, if I, for example, click "Add" there is nothing to determine which table should have the record added to it. Also, if I'm editing (or adding) a record to the Expense table (controlled for navigation by a grid), I don't want the fields that are in the expense detail to be enabled when I'm performing an edit/add to the Expense table.

So the "obvious" answer seemed to be to have two sets of identical controls for the add, edit, delete, etc. functions, but I was trying to think of another application I've used where that was the case, and I couldn't come up with one. But I also couldn't find a good way to manage this issue.

I thought about adding an additional form level property called lExpenseEnabled which would be used to control the state of the expense table items during an add/edit but it still didn't resolve my problem with not knowing which table was to be added or edited. I thought maybe some of you have had this issue before, and looking for an elegant solution to this.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Very general, this is a 1:n form with subform. You wouldn't want a form per expense detail, of course, but I would have a parent expenses list form and a form for a single expense with all its details.
The nav buttons, especially the add button on the parent form then means adding a new expense and starting its form with empty expensedetail list. In the expense form the add button will add an expensedetail.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Scott24x7]

Hi Olaf,
But that's kind of what I'm trying to avoid. I don't want 2 forms, one for "header" and one for "Detail". I wanted to keep the "header" in the top, you navigate to different expense reports in its grid, which then updates the detail grid in the same form. But sounds like I have no way around having 2 sets of control buttons if I do that. One to manage the Header and one to manage the detail?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[foxincloud]

maybe this design:

http://foxincloud.com/tastrade/bs/

 

[Scott24x7]

Hi Thierry,
Yes, I had already considered that, but it ends up with a dual tab option. The larger problem there is, there just isn't enough "detail" for a tab. I don't like giant amounts of white space (a full tab) for 8 fields of data. Another visual ugliness I'm trying to avoid. Not sure that I can get around it though, one issue or the other.
Still thinking about it.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Scott, this looks to me like a classic parent-child interface. The way I have always done that is for the main form to show the header fields in textboxes, combo boxes, checkboxes, etc. And a grid to show the detail fields, one detail line per row. The grid is always read-only.

The user can put the form in edit mode, at which point the textboxes, etc. become editable. But the grid remains read-only.

When the form is not in edit mode, the user can double-click on a row in the grid. That will bring up a small modal form, in which the user can edit the fields for the relevant detail item. There is no Save button on this form. The detail table's buffer is updated when the modal form is closed, at which point the grid is refreshed.

Both tables are buffered, with updates being committed at the same time.

The main form can also have buttons for adding a new detail item or deleting an existing item.

I appreciate that this doesn't fit in exactly with the requirements you have described, but I have usually found it to be a sound user interface, which users find easy to understand.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[foxincloud]

don't like giant amounts of white space (a full tab) for 8 fields of data

current design tends to leave much 'respiration/breathing' space around oversized controls:

http://getbootstrap.com/docs/4.1/examples/checkout/

 

[Olaf Doschke]

Scott, you didn't listen, the second form would have the combination of expense head data and list of expense details for one expense. So you mainly one use the parent form to get the overview list and either find an expense you want to edit or add a new one, which is done in the child form. Of course, the child does not only have the expense details, but also the expense head data for entry/edit. Because the parent list/filter form might not even display all details of the expense header as it doesn't fit into a list, nicely. What this still solves is no need for two navbars in the same form. And the possibility that adds is seeing two expenses with their detail in parallel with two of the child forms opened.

I've also done single forms with three or more levels of hierarchy, you don't have to use navbar buttons, I don't think this concept works well anyway, you'll have specific add buttons in the separate lists that are 1:n:m related or you display a hierarchy in a treeview and define context menus for nodes to add items (sub-nodes), or to copy a branch and paste it (e.g., use a similar expense as template for a new one). You're not bound to a standard, which mainly is intended for a single table or - as I proposed for the head table of a structure only.

I say users are too keen on having something in a single form, if you want more rigid similar interfaces with things like a navbar you can only be that consistent, if you split, at least into pages of a pageframe.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Scott24x7]

Olaf,
AH, I see the distinction you make now. And I see how that could work nicely, and still satisfy both the needs. I will give this a bit of a rethink, and then try implementing it like that. So I can have a "New Expense" button in the expense detail that pops a form that allows me to create a new expense, with it's own button set. This form would allow adding or editing an existing new expense "report" header. Then when it closes, those headers are in the grid on the detail form which is where you spend 99% of your time. Can't modify it there but it creates a context for the details contained in the detail grid, and you can navigate it easily there too from the header grid... I like this idea!


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

One reasoning I often hear aside of the effectiveness users think they have by not needing to move around between several forms is, a simple head data (list) form hides the details you only see once you start a detail form, you have to know that's possible. But that's a matter of training new users and designing the interface to highlight controls, which expand (not expand themselves, but the overall interface by starting further forms). The argument everything in one place is not that striking, you can only concentrate on one thing anyway and having split forms supports that, especially if you handle the positioning and tiling of the screen with forms in a nice way and have a system to easily cycle through forms, eg a well known hotkey or controls for that in the same header/footer place in all forms.

The urge is there to want to see the child form side by side with the parents, so you don't forget there's that parent form. The docking of forms is a thing that could be sued here, it'll create a pageframe of tabs at the bottom of the docked forms. It's not always ideal, as the two parent/child forms can have very different sizes but it allows to have a group of parent and all its child forms docked together and you could react with resizing to the natural size of the active form tab, but you could also make it a norm to take the largest size of a family of forms the norm for all of them and leave spaces. Its a good idea to have all forms resizable with a good concept of using the anchor property and containers within forms to tile them internally for easy and logical resizing.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Scott24x7]

Olaf,
Thanks for the additional insight. I'm spending some time to think through the model (rather than just staring to make forms) and some of the points you've made here confirm some of my thoughts, and change some of them as well. So this is great, and just the kind of thing I was hoping the members could provide some guidance on.
I'm hoping I can get it all running in the next few days. Big help on this, thanks very much!


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."