posted
I feel kind of cheesy asking this, but goodness knows I've tried other channels. The company I'm working for right now is programming in VB.net. This is non-negotiable, so, while I sympathize with all the "What are you doing programming in that?" responses, they're not going to be terribly helpful for me.
Anyway, I knew VB6 and I'm getting pretty good at VB.net, but I'm having some real problems getting up to speed with GUI design.
I've got two main questions. First, should I just abandon the MVC model here? From what I can tell, they're not real big on separating the model from the view except in the case of data-bound controls, which are often far more tightly bound than I would like. Is it quixotic to want to write separate models that are passed to the controls?
Second, I've got a specific problem in that I want to put drill down functionality into a table type view (from what I'm seeing, either a ListView on "Details" or a GridView, but I'm open to others). That is, I've got a series of data rows that can be summarized by a super row or that are associated details from a super row that I'd like to only show if the user wants to get into the details. Is there an easy out-of-the-box way to do this?
Thanks, and I feel vaguely not right about this.
Posts: 10177 | Registered: Apr 2001
| IP: Logged |
posted
Fahim says, in regards to the MVC (model, view, control) approach, they're not. Most VB apps don't work on separating the business logic from teh presentation. You can separate it, but most people don't. Fahim usually gets a third party controls and uses that rather than MS out of the box controls. MS controls are limited, so he uses developer express or something like that.
I don't know what most of what I typed means - oh, I understand the individual words just fine, but that particular combination? Nope. Fahim dictated, I typed. I hope this at least makes sense for you and possibly even helps. He's busy doing something else - he has a couple of programming projects on the go right now, and I suspect that that's what he's concentrating on and doesn't want to lose focus.
Posts: 8355 | Registered: Apr 2003
| IP: Logged |
quote:Is it quixotic to want to write separate models that are passed to the controls?
Well, is there something you want to accomplish with this? If so, no. If no, yes.
quote:Second, I've got a specific problem in that I want to put drill down functionality into a table type view (from what I'm seeing, either a ListView on "Details" or a GridView, but I'm open to others). That is, I've got a series of data rows that can be summarized by a super row or that are associated details from a super row that I'd like to only show if the user wants to get into the details. Is there an easy out-of-the-box way to do this?
There are a handful of ways. If you just want to display additional columns that aren't being shown on the summary level, use collapsing grouping; a quick web search on "grouping listview" will give you some examples. (Believe it or not, though, grouping isn't really an "out of the box" option. God only knows why.) Otherwise you want to insert a button into the control -- you'll need to use a control which accepts buttons, which luckily isn't a problem -- and have the OnClick for that button pull information from the row it's on (either by grabbing the row's index and matching it up to your rowsource, or just pulling the text out of the exposed controls (which is best if you're doing, say, an "update" button.))
Posts: 37449 | Registered: May 1999
| IP: Logged |
posted
VB.NET should be far better at handling modern gui design than vb6. I'm no expert in VB (any version), but I'm pretty familiar with the overall structure of some of the .Net libraries and with good design.
While its obviously 'easy' to bind directly to backing data sources (and probably appropriate for many simple applications), if you're writing something more complex, you should be wrapping or otherwise abstracting with one of the supported interfaces, then binding to that: http://msdn2.microsoft.com/en-us/library/system.windows.forms.datagridview.datasource.aspx
It appears ListView will be what you go with. In particular, it provides capabilities to override how it displays individual things and display them as you like instead. While it might not do what you want out of the box (I can't tell, as I find the descriptions of functionality in the MSDN documentation badly written, and lacking something that would be extremely useful: pictures -- http://msdn2.microsoft.com/en-us/library/system.windows.forms.listview.aspx ), it should be pretty easy to modify for your purposes if it doesn't.
Posts: 15770 | Registered: Dec 2001
| IP: Logged |
posted
.Net actually makes it pretty easy to write separate models. As long as the model class generates a dataset object (working from memory here), most controls should be just happy using your model.
I almost never bind controls to the data store as far as updates go. I like to populate when appropriate and read and save all at once when appropriate. But I often would bind the contents of things like grids, trees, and listviews to the data store.
I don't know if our apps would be formally classed as MVC, but there was clear separation of the model from the GUI. We often used the same model objects for a .Net Windows app, a web app, and a Mobile app, with no changes whatsoever. I think that's a pretty good indication the model was separate from the view.
I enforced such separation rigorously, so it can be done and it definitely saved us time (our specifications were fluid, to say the least). Unfortunately, I last did this in 2003 so I can't offer specifics. But I can say yes, it's worth using MVC with .Net and is done fairly often.
Posts: 26071 | Registered: Oct 2003
| IP: Logged |
posted
Thanks. That's very cool and gave me a lot more to work with than about a half day of web searching. Yay for the Hatrack geek community!
Posts: 10177 | Registered: Apr 2001
| IP: Logged |
Printer-friendly view of this topic
![[Smile]](smile.gif)
