I have a complex WPF Tab control inside a main main window, all in C#, using .NET Framework. The main window provides a consistent main menu and a contentcontrol holding the Tab Control.
Each tab of the tab control presents a different usercontrol using a viewmodel specific to each usercontrol.
Before going down the rabbit hole, I need to know if Elmish.WPF can provide the proper F# backing for this situation.
In studying the examples, the key handoff to Elmish.WPF seems to occur with:
Program.mkSimpleWpf App.init App.update bindings
Once the main window and the first tab are presented, can init, update, and bindings be discriminated unions allowing the user to switch between the tabs? If so, can the new tab state be "fed" into Elmish.WPF?
Any help or suggestions would be most appreciated.
TIA
(To further complicate matters, one of the tabs presents a datagrid with custom adorners for list manipulation).
I am a maintainer of Elmish.WPF.
I have a complex WPF Tab control inside a main main window, all in C#, using .NET Framework. The main window provides a consistent main menu and a contentcontrol holding the Tab Control.
Each tab of the tab control presents a different usercontrol using a viewmodel specific to each usercontrol.
Before going down the rabbit hole, I need to know if Elmish.WPF can provide the proper F# backing for this situation.
For this scenario, yes, there should be no problems. We currently have no samples in the repo that use tab controls, but in general, everything you can achieve with bindings (and then some) in WPF can also be achieved in Elmish.WPF. Please open an issue in the Elmish.WPF repo if you are unable to get it working after studying the samples and official tutorial.
Once the main window and the first tab are presented, can init, update, and bindings be discriminated unions allowing the user to switch between the tabs? If so, can the new tab state be "fed" into Elmish.WPF?
I am a bit unsure what you're asking here, but it is possible you are confused about some central MVU concepts. The Elmish.WPF tutorial or other resources mentioned in the Elmish.WPF readme may be of help. In general, the message type is a discriminated union, and the model is a record. On the other hand, init, update and bindings are functions that act on the model and the messages.
(To further complicate matters, one of the tabs presents a datagrid with custom adorners for list manipulation).
I'm no expert on WPF tab controls, but AFAIK the contents of the tab should not impact in any way whether Elmish.WPF works with a tab control.
Related
In a moderately complex database application in Delphi it's easy to have dozens of datasets (tables and queries) and associated datasources on a form.
All these clutter up the screen.
It gets worse when your form has a pagecontrol where every page has its own set of datasources et al.
If the Tables and Datasources were visual controls, at least they would only be visible on the Tabsheet where they're applicable.
I've thought about creating some container object that could hold many datasets and datasources, but never got round to it.
I also have cnPack which adds to option to hide non-visual components from view in the designer.
However this is not helpful because it makes it hard to select them.
What's the solution to unclutter the form designer whilst still having the option to select the data access components?
(For what it's worth I'm working in Delphi 2007 and XE2)
You could create a data module for each logical group of non-visual components. Then name the data module accordingly so you can relate it quickly to the page the components belong to.
www.gexperts.org has a IDE plugin for delphi, which contains an option to hide/show all non-visual controls.
It is perfect for hiding all of the datasets etc so you can manipulate your components. You can then show them again when you need to access them.
To make life even easier you can customize the toolbar so you can hide/show them in a single click.
You can write your own small expert or component (like this one) to hide nonvisual components you need and store them in groups.
more and more frameworks are trying to separate navigation rules from code. for example, JSF got "navigation-rule" tag in faces-config.xml to control page flows. new xcode 4.2 introduced storyboard so developers don't have to write code to handle navigation between scenes.
my question is why it's so important to separate navigation flow from code. what's wrong with writing code in controller to handle pages flow?
Off the top of my head: having a navigation flow specified in a single place makes it easier to understand a codebase you're not familiar with – you can see exactly how you can get to a given view without having to hunt this down.
You mention the storyboard editor in XCode – another advantage would be that having the navigation structure as a first-class entity makes it toolable.
If your framework (maybe one of the umpty Java page flow frameworks?) also checks whether a user sticks to this flow, it's possible to easily catch errors that would happen if the intended flow is violated. (E.g. if the user tries to open the middle of a "wizard" type interaction.)
Using such a framework imposes a cognitive overhead compared to "straightforward" code. That doesn't mean you should ignore patterns at abstraction levels higher than "controller method code", or you'll turn straightforward code into spaghetti code. Obviously the benefit of formalising your navigation flow increases with the number of views in your app and the complexity of the connections between them.
What are the main differences between the Implementation tab and the All Link tab in TFS 2010? I ask, because we have a need for Requirement work items to have an Affects/Affected By (or maybe Predecessor/Successor) link type with Task work items...instead of the parent/child link type you are limited to in the Implementation tab. Essentially, we want the ability for a given task to be able to have links to multiple Requirements.
As extensible and free-form as TFS 2010 is...I still hesitate a bit to go this route without knowing what kind of possible negative impact this approach could have when it comes to future reporting needs or something else.
Any thoughts? Thanks!
The implementation tab is constrained to only Task work items that are children of the Requirement. The All Links tab shows every link associated with the Requirement (including Tasks). The FORM section of the WIT definition defines the layout... and the links controls. You can adjust these tabs (or add new ones) there.
As for this particular change, I would tread carefully. Having tasks with "multiple parents" can lead to a lot of confusion and over-engineering. I've seen many teams try this approach only to abandon it in favor of a simple parent/child relationship.
What is the main reason for wanting tasks to be tied to multiple requirements?
The program WinDirStats (written in C++, see http://sourceforge.net/projects/windirstat/ ) has at the top a control that combines a tree-like structure (The column "Name", first on the left) with other types of data (graphic bar in column "Subtree percentage") and other text columns.
My question is, using Delphi 7, which control should I use to do something like that? It's the tree part that I find more difficult to get right.
The best control for this would most likely be Mike Lischkes Virtual Tree View.
Developers Homepage | Google Code Page
It's free
It gives you a tree connected with a list view
It allows for custom drawing
It's incredibly flexible
It's lightning fast
The only downside is that you have to learn a quite different paradigm than most Delphi controls have, but apart from that it is a teriffic control.
I myself have used it in various projects quite successfully and never hit a real roadblock while using it.
I also prefer Virtual Treeview, but here are some commercial alternatives:
ExpressQuantumTreeList
ElTree
TTreeList
The well known Command pattern is used often when you want to implement a model with Undo/Redo capabilities. I am looking for a reference implementation (example) of a simple Delphi form that implements undo/redo.
From what I have seen, simple delphi data-entry forms with three Edit boxes, six memo boxes, and a few combo boxes and other simple edit controls, do not typically support Undo/Redo.
Has anyone seen a well designed delphi approach to multi-level undo/redo support for a complex model-view-controller design using a separate Delphi view (form), and model objects (data objects are updated synchronously with all edits to the form, and the validation and control logic is not embedded in the form, or in the model, but separated out.
It seems to me that if you didn't have to use MVC, and you needed to simply prototype a Delphi demo app that had no model or controller objects, that Undo/Redo of a pure simple Delphi "one-form-is-my-app" would be simpler to design, but it would get more complicated as you need to record and replay objects and synchronize them to Delphi form actions like TEdit.OnChange.
You should use followings patterns:
Model-GUI-Mediator -- synch between objects model and GUI control, so you are no limited by TDataset and DB-Aware controls. You can create object-aware controls from EVERY VCL controls.
Command --your ACTIONS on the objects model. Should be fired by Controllers.
Memento --saving internal state of Data Objects for implementing the Undo/ReDo behavior
ASAP I'will post a simple example on my blog www.danieleteti.it
I'd probably base that on a ClientDataSet: that has undo capabilities (and if I remember correctly, it is pretty easy to implement redo with it as well).
Bonus: you can use data aware controls.
I have a feeling you are looking for some kind of ORM like behaviour.
At DelphiLive I will be speaking on doing a kind of ORM layer based on ClientDataSets; they are pretty cool.
--jeroen