|
The transformations you get from ScaleTransform and the like are cumulative, so child bones get their parent's matrix automatically; you do need to add an undo, so just before End Sub insert
Undo Rotate and Translate Graphics transform with LOCAL matrix values
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Question:
My company has recently bought some fancy usercontrols on the net.
These controls can do a lot, but some of them require databinding.
This is something I am not familiar with and neither is my company.
I am quite convinced of the advantages of databinding, but not when it's done in the designer. The designer generates a lot of code, both in VB and SQL and puts lots of items in your toolbox and componentstray. Bottomline is that I have no idea what I'm doing in the designer. But this is also because I'm not familiar with creating datasets in the designer.
So what do you say? Should I just keep on trying and make my dataset, tables and binds in the designer or is programming the whole thing easier/more scalable/better maintainable etc.? What are the pro's and cons, code vs. designer.
|
|
|
|
|
IMHO, using the designer limits your options and creates a ton of "mystery" code that goes in places you're not aware of.
I never use the designers for datasets. I prefer to write my own code for simplicity and maintainability.
BTW: Databind is done all the time without using the deisgners. When you set a DataSource property to some collection or DataTable or DataSet, you're doing databinding. I can't believe nobody in your company knows about this.
|
|
|
|
|
We never use the datasource property.
We always fill every cell in a datagrid or every textbox on a form programatically.
There's a bit more to it than that, and there's some benefits to it.
But let's just say we really never use databinding 
Databinding has always been a kind of taboo. Until now.
And the more I do with it (design-time), the more it becomes taboo for me again 
|
|
|
|
|
If/when I use datagrids I make them readonly, and bind(set the datasource) to a
list/array/collection of something. And edit/modify the data through dedicated popup windows/user controls.
All the best,
Dan
|
|
|
|
|
Naerling wrote: We always fill every cell in a datagrid or every textbox on a form programatically
Wow. Talk about a ton of code that's slow to fill a grid and could all be replaced with a single assignment statement.
|
|
|
|
|
Sorry for the long answer but here goes.
If you ask me don't use design time databing, hell even better(or worse depends on taste) don't
use datasets/datatables.
I had some experinces with datagrids and automated vodoo magic that were very unpleasant. I
just didn't have a clue at was the error was.
Since then I always create classes or structs/enumns depends on the job ata hand.
Anywho I always create classes that map the tables and/or business model and use
Datareaders to get the datas in those customized object models. It takes a little longer to code
but the benefits of debugging itself not to mention maintanability/scalability...
are totally worth it.
- You are in control.
- You tell it(the app/progra) what to do. Not some vodoo magic and pray to god it all goes well.
Maybe I'm beeing a little extreme but I wouldn't use for anything in the world in a real world app.
Sure some quick and dirty tests and the likes, yeah go ahead saves time. But real world apps NO.
Just my thoughts.
All the best,
Dan
|
|
|
|
|
I was kind of thinking the same thing. But I do want to give datatables/sets a try.
We are now working with lots of classes and properties.
But it's a lot of work, especially if you have some master detail stuff.
Actually we're all kind of tired of having to type:
Textbox1.Text = datarow("field1")
Textbox2.Text = datarow("field2")
Textbox3.Text = datarow("field3")
...
Textbox50.Text = datarow("field50")
You get the idea
|
|
|
|
|
Naerling wrote: You get the idea
yeah, you really should choose more descriptive TextBox and field names.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
|
Something like txt1, txt2 right? 
Just think about the cost/type reduction. 
All the best,
Dan
|
|
|
|
|
Har har... Har
Using connection As New SqlClient.SqlConnection(My.Settings.MyConnectionString)
Using cmd As New SqlClient.SqlCommand("select * from smartasses where name = @name", connection)
cmd.Parameters.Add("name", SqlDbType.VarChar, 50).Value = GetUserFromPostAbove()
connection.Open()
Try
Using reader As SqlClient.SqlDataReader = cmd.ExecuteReader
While reader.Read
Dim gridRow As New DataGridViewRow
gridRow.CreateCells(gridSmartAsses)
gridRow.Cells(gridSmartAsses.Columns("name").Index).Value = reader.Item("name")
gridRow.Cells(gridSmartAsses.Columns("age").Index).Value = reader.Item("age")
gridRow.Cells(gridSmartAsses.Columns("message").Index).Value = reader.Item("message")
gridRow.Cells(gridSmartAsses.Columns("funny").Index).Value = reader.Item("funny")
' ... Up to about 20 columns.
gridSmartAsses.Rows.Add(gridRow)
End While
End Using
Finally
connection.Close()
End Try
End Using
End Using
That's just no way to fill numerous grids with 15 to 20 columns 
And I know this query looks like it will return only 1 smartass, being GetUserFromPostAbove() (and yes, that name IS in the table :p ), but you can see why we don't want to fill our grids like this anymore
I never use the SqlClient namespace by the way, we have our own simplified company tool which is top secret! 
So feel free to comment on the code as you see fit. I am here to learn as well
|
|
|
|
|
Urghhh VB.
Please take your capitalisation out of our pristine, brace friendly forum.
|
|
|
|
|
All those
gridRow.Cells(gridSmartAsses.Columns("name").Index).Value = reader.Item("name")
lines are identical except for a string, so you could "for each" them with the string pulled from a collection. In the end I would stuff the entire try block into a separate method, that is generic and needs to be written just once.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
So you'd pass the datagridview and two list(of string) (column names and field names are not always equally named) to a function called FillGrid or something?
Sounds like it would work, but then you'd have to iterate through gridcolumns and datatable columns
And if you have some exception like gridRow.blabla.value = reader.Item(0) & reader.Item(1) it wouldn't work, or if you want to colour every row where (some condition) or... And we do that sometimes
Actually those were the advantages of filling each row seperately.
But I guess that's not possible with databinding either... 
|
|
|
|
|
If that was meant as a question, then yes you pass parameters for everything you want to be able to change from the outside. As always. And you can forgo exception handling inside the method, and leave that to the caller, as he is more aware of what should be reported if and when something goes wrong.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
The real answer to your question is "That is the question".
Hope it helps. 
All the best,
Dan
modified on Wednesday, January 26, 2011 3:14 PM
|
|
|
|
|
No, that is the question...
|
|
|
|
|
Naerling wrote: Actually we're all kind of tired of having to type:
..how about generating it?
I are Troll
|
|
|
|
|
Naerling wrote: These controls can do a lot, but some of them require databinding.
To what, actually? I'm binding a lot from generic lists and array's, as a quick and easy way to display data.
Naerling wrote: This is something I am not familiar with and neither is my company.
There's always MSDN[^] 
I are Troll 
|
|
|
|
|
Sure there's MSDN, but they won't tell me to not use their designer features 
|
|
|
|
|
Are you using the "Settings"-tab in the project page? That's a code-generator too
The page on MSDN describes databinding in a more broad sense then binding an ADO table to a grid. Your 3rd party controls might want to bind to CLR-properties. What does the documentation of the 3rd party controls say?
I are Troll
|
|
|
|
|
We don't use the settings tab
And I'm not really against code generation as long as I know it is good code. But selecting two datasources for two datagrids (master/detail) (from the datasources wizard in the designer) generates 6 items on my form and SQL statements such as "DELETE from SomeTable WHERE (every field in that table) = (every field in that table-variable)" even if there is a PK on that table. If I switch datasources in my grid I could end up with identical items called 'DataBindingItem' and 'DataBindingItem1'. And if I use a BindingNavigator I can use a 'Save' button which gives me exceptions rather than messageboxes if I leave some values empty, so I'd still have to write all validation logic (even though it's known from the datasource).
So that's why I was wondering if this wizard for datasources is all that good. The documentation of our third party tool uses it all the time. Although they give some code examples using DataAdapters too.
Nice MSDN article btw
|
|
|
|
|
Naerling wrote: We don't use the settings tab Smile
That's a good start
Naerling wrote: And I'm not really against code generation as long as I know it is good code.
You think that Microsoft would put a generator in Visual Studio that would generate code that would look like it's written by a student?
Code Generation is cool, as long as you know exactly what it's generating, and why. I'm using the settings-tab sometimes, because I know what to expect and I'm pretty sure that there won't be any surprises there. I'm not using the dataset-designer, because I'm not intimately familiar with the code that gets generated - it's a foreign architecture to me, and I'd be lost if something went wrong.
Naerling wrote: But selecting two datasources for two datagrids (master/detail) (from the datasources wizard in the designer) generates 6 items on my form and SQL statements such as "DELETE from SomeTable WHERE (every field in that table) = (every field in that table-variable)" even if there is a PK on that table. If I switch datasources in my grid I could end up with identical items called 'DataBindingItem' and 'DataBindingItem1'. And if I use a BindingNavigator I can use a 'Save' button which gives me exceptions rather than messageboxes if I leave some values empty, so I'd still have to write all validation logic (even though it's known from the datasource).
So that's why I was wondering if this wizard for datasources is all that good.
It's doing more bad than good, most of the time. It's not been used in any of the shops where I worked, with a single exception where it was considered a nice tool to create prototypes.
Naerling wrote: The documentation of our third party tool uses it all the time. Although they give some code examples using DataAdapters too.
I'd expect that there'd be an alternative way to load data? Otherwise it'd be useless with a tool like, say, SharpDevelop?
Naerling wrote: Nice MSDN article btw Smile
Thanks
I are Troll
|
|
|
|
|
Eddy Vluggen wrote: You think that Microsoft would put a generator in Visual Studio that would generate code that would look like it's written by a student?
I've heard people talk about Microsoft stuff generating SQL queries that would put them to shame
We now use data-binding and datasets (in designer) for a proto-type too. But since my employers really want to do less coding and a less-skilled collegue can do all sorts of stuff in the designer he wouldn't be able to do in code I guess it's designer data-sets for us from now on...
I'm not 100% sure, just 99%
Pro's: Microsoft generates code for you, it gets the data for you, it only updates rows that are altered, even my boss can do it, it's fast.
Cons: none.
<blockquote class="FQ"><div class="FQA">Eddy Vluggen wrote:</div>I'd expect that there'd be an alternative way to load data? Otherwise it'd be useless with a tool like, say, SharpDevelop?</blockquote>
Yes, you can use the DataSource and DataMember properties of a control. Last week a collegue was able to directly call a cell in a grid using 6 or 7 DirectCasts... I guess we'd rather use databinding 
I don't know SharpDevelop or any other tools 
By the way, if I would build up a dataset in code and I wanted to bind, let's say 50 controls to 50 fields, do I have to bind each one of them seperately? That would kind of be like how we do it now, except now we only fill the Text property of a textbox... 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
