Right now I use 2 arrays one of TImage the other of TMemo to draw an image next to text data row after row inside a scroll box.
I am looking to replace the TMemo with several components on a Panel. So probably some static text a button and some labels. But the way I'm doing it now it seems as if this will become messy.
Is there a better way of going about this without writing a component or class. Should I be using some sort of multi dimensional array or can I use a record structure to declare the components and have an array of that?
A record would at least relieve you of the burden of managing lots of parallel arrays, but you can do better than a record, and better than an array.
First, you can design a frame to represent one "row" of your form. Give it an image, button, label, and whatever else you need. Then create an instance of that frame class each time you need one. It will create the components for you automatically. You said you didn't want a custom component, and that's essentially what a frame is, but by getting to design it visually like you would a form, much of the burden of creating a composite control is lifted, so you just get the benefit of a group of related controls that can interact with each other as a unit.
Instead of an array, you might find better success with a different collection object, especially TComponentList which can grow and shrink more easily than an array, and also helps manage ownership of its contents.
Related
I'm trying to improve the real-time log display of a rather complicated system. Currently there is a significant tradeoff between situational awareness (improved by displaying only high-level events) and reproducibility (which requires lots and lots of details). The obvious approach is to structure the details as a tree and allow their display to be expanded and collapsed.
The existing implementation uses just a RichTextbox. I'd like to use MVVM for my rewrite, not only because it's a best practice but also to enable behavior such as "Show details of an operation while it is ongoing, then automatically collapse them once it has successfully completed.".
As a further complication, the log records have some structure, which needs to be displayed in a columnar format. The nesting should be accomplished using the description column only (can be through pure indentation, as depicted, or using tree lines).
Can you recommend a way to map this data structure onto WPF template elements? There doesn't seem to be a way to produce a sequence of DataGridRow objects from a parent object. And because the rows do not have uniform height (some of the detail data is multiline), trying to use a WPF tree for the description and then synchronize the vertical placement of data in other columns doesn't seem feasible.
Will I have to give up on the idea of a data-bound model, and use more of a view-controller design with manual creation of WPF elements, with references to these elements such as DataGridRow stored explicitly within the in-memory tree structure, and implement collapsing and expanding by iterating through the child items and updating each descendant's Height property of the associated WPF element object?
And if I do break the data/presentation wall and use imperative coding style, is there something similar to WinForms SuspendLayout/ResumeLayout that I can use to achieve just a single layout pass per collapse, no matter how many rows changed in height?
Here is a quick mockup of the tree structure made using WPF+XAML. It's just a Grid without any document structure -- all the text elements are direct children of the Grid with manually set Grid.Row and Grid.Column attached properties. Clearly that would not be suitable for an implementation with new data and structure being generated in real time.
Is there a way that would allow me to create tables within a view controller and then position them? I have an array "items" that would output the total amount of TableViews -1. So for instance if the array "items" contained 15 items, 14 TableViews would be created.
Can you add n tableViews to a single view controller? Yes, but it's not practical or reasonable to write the amount of code you'd need to manage a varying number of layouts and delegates.
A tableView is designed to scroll (sections or) rows of cells, not to show a single item on screen. If you are determined to layout each item, you would be better off using a (much lighter) custom view instead of a tableView.
However, a single UICollectionView can do what you want to do. Yes, you'd have to write some code to manage the flow layout, depending on the number of brackets it had to display, but you could easily manage a grid-based approach with each column (round) showing teams and score.
This would certainly be more intuitive and practical to have a single scrollable region, where each bracket is able be selected and interacted with, instead of trying to add multiple tableViews to a view (controller).
I wrote my own sub-class, for some selection stuff and paging etc. But those all worked with the renderer(), which required them to return a string.
This worked fine, I created some image-tags and returned those.
But how does this class work in detail?
I want a sub-class which displays a chart in a cell, which should technically be no problem, but the renderer() doesn't seem the right place for it, since it only works for strings.
Does the Class get instantiated for every row? or is it really just one instance for a column, which methods get called for every row with the needed data and the instances don't hold any state about the rows?
The renderer() mechanism is actually implemented in Ext.grid.column.Column, for which there is one per column.
As you have mentioned, the renderer() function returns a string, which could be an HTML string (which could be rather complex - have a look at the templates used by ExtJs for the standard columns). But you cannot return a component (chart).
To the best of my knowledge (based on my own understanding and replies to similar questions), ExtJs does not offer a straight-forward way to render components within grid cells. If you really think about it - you are asking a grid for much more than its intended role. It was designed to present records per raw, with the addition of simple user interaction facilities, like checkboxes.
But what you are really asking for is more of a way to layout charts, for which problem i suggest you look into the Table layout.
Alternatively you should be able to render a chart into a dom element, which will be defined in your own custom column template. But I will consider this to be an involved task.
I got a pretty big form on a wpf page. I'm putting it together on a Grid, but all the element clutter the page. I figured i'd split out the form into smaller usercontrols and then piece it together on the page as one form. That didn't quite work: SharedSizeScope on a Grid makes the form 'dance'
I could break up the form into a 'wizard style' page, with a next button - dealing with each user control on its own, but i'd rather not break it up into several pages because the end user is used to having it all on one page. Also the validation/storing of data is really a big-bang operation, making it harder to provide feedback if something goes wrong in one of the first pages/usercontrols.
So what now? I'm really tempted to just put all the small elements directly on the page in one big grid. I just feel it's wrong - it will be a maintenance nightmare - i even started thinking 'i wish there were some kind of #region tag in xaml' - that means i know i'm wrong ;)
What can i do?
I would strongly recommend to use nested container controls, like Grids (or other Panels) inside other Grids inside more Grids etc.
It is very common to have several nesting levels, and thus hierarchically split a complex layout into multiple less complex sub-layouts. This makes your layout significantly simpler compared to one big container that tries to do it all (see your failed ShardSizeScope approach).
Once you have created a sensible hierarchy of containers, you may easily use the Visual Studio XAML editor's code collapsing feature to keep track of all your XAML.
When building WPF forms that are used for data entry (e.g. A bunch of labels next to a bunch of textboxes and comboboxes) I've seen two methods:
Create a master Grid, divide it into two columns, and add rows with Height="auto" for each field and two rows for header and footer (and submit button), and each label and text box has their own row.
The other method is to create a master stackpanel and inside it a horizontal stackpanel for each pair of label-textbox.
How do you design your data entry forms? I'm currently torn between the two methods, maybe there's an alternative that I'm unaware of?
EDIT: Henk said I should define best and I think I agree, by best I mean easiest to maintain, create, align and add or remove fields from as demands change.
So far the only criteria by which the grid is better is ease of alignment.
definately first method!
it's well aligned, especially with the use of SharedSizeGroup so you can have the same alignment eg in different Groupboxes.
I have used both and it really depends upon how your form is going to look. If you have a really simple layout where you are going to have labels and and corresponding fields of approximately the same size then your first method works well. It lets you create two columns that line up very well. However, if your fields are of varying withs, and heights and you want to be more complex with the layouts then a hybrid approach may be best. If you are doing anything more complex than just labeling fields on basic controls you may want to create user controls rather than just using what is there out of the box. When laying out fields in both a horizontal and vertical jagged manner it becomes hard to maintain the grid layout as you have to wind up having a grid with lots of columns and rows. The fields and labels have to span columns and rows to get your alignment correct. This works, but is a nightmare if you ever want to reorganize the form.
For what you wrote, it sounds like the first approach is best. If its simple now and some point in the future it becomes more complex, its easy to change. However, if you have a more complex layout already then a pure grid based approach probably isn't best.
Disclaimer: I am going to say little about my own company's product in my blog that gives comparison and challenges in maintaining forms.
Both Grid and StackPanel have Maintanence nightmares so we went on different approach of creating Form Layout, and I have outlined our approach here on this link,
http://akashkava.com/blog/296/advanced-data-form-with-ui-atoms-on-wpf-and-silverlight/