|
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... 
|
|
|
|
|
Naerling wrote: 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.
Cons:
* Unexpected bugs within the framework
* Missing hotfixes/patches
* Limited in it's uses
Yes, it could be considered a time-saver at moments. Others claim that it costs more time than it's worth. So, the best idea would be to "try", create on with the designer and one with a reader using BO's, and compare them -use them when it makes sense
Naerling wrote: 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 depends on the inner working of those 3rd party controls. A Grid might be able to deduce columns from the meta-data, but textfields, comboboxes and radiobuttons need be bound often by hand. Either in code, or by clicking together those mappings in the IDE.
Good luck
I are Troll
|
|
|
|
|
Thanks for the help. I think I know what I wanted to know.
I hope my company will soon see that the designer is not the answer to everything and that's it's no holy time-saving money maker 
For the moment it doesn't hurt to try
|
|
|
|
|
There is a bit of a learning curve to handling binding of controls but once you understand how it works, in most (not all) cases it will save you a lot of time and your company a lot of money.
At the moment go with what you know but spend the time to learn how binding works. It's very much a part of WPF and Silverlight.
Architecture is extensible, code is minimal.
|
|
|
|
|
Based on experience, binding through design is always harder to maintain - somehow I prefer to do this through programming.
But whatever you decide, make sure it is documented and followed as a standard.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
|
|
|
|
|
Can anyone help me basically my situation is as follow.
I used to develop in .net 3.5 sp1 using visual studio 2008
I was able to run/debug my program without any hassles whatsoever.
Then I recently upgraded my solutions to .net framework 4 on visual studio 2010
My programs still run fine but when i try to run it in debug mode i get the following exception in visual studio,
An unhandled exception of type 'System.StackOverflowException' occurred
If anyone can point me to something i can do or a hotfix for this i would be very happy.
My System a Dual CORE CPU 4 Gigs ram running on a 64 bit windows 7 operating system.
I do my development inside an XP Pro(32bit) virtual machine (VMware) 2.5 gigs of ram allocated.
Many thanks
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
Unfortunately, this is one of those situations where you're going to have to do a lot of debugging yourself. You're going to have to set breakpoints in your code at strategic locations and start refining from there. Two things:
Does this only happen in debug?
Have you changed any code when you upgraded?
|
|
|
|
|
Yes this only happens when i debug, and the code is a precise exact copy of what I had , aside from the fact that the projects are set to .net framework 4; also setting this back to 3.5 sp1 does not change anything
From what i gather this error seems to be loosely related to COM classes that i am using , the second i try to run code associated with that com interop it gives me this error , I got a loader lock warning at the beginning and I told the debugger to ignore it now i am stuck with this stack overflow.
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
There's your problem then. The Loader Lock was introduced in VS2005. From MSDN[^]:
"The loaderLock managed debugging assistant (MDA) detects attempts to execute managed code on a thread that holds the Microsoft Windows operating system loader lock. Any such execution is illegal because it can lead to deadlocks and to use of DLLs before they have been initialized by the operating system's loader."
|
|
|
|
|
Then why was i able to debug my application in version 2008 and now in 2010 version I cant.
Is there any workarounds/hotfixes that will be able to help me ?
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
.NET 4 is a complete overhaul of .NET rather than an upgrade path from .NET 2.
It sounds like the problem's actually in the COM part. Have a read of the link I gave you (specifically the Resolution part) and follow the links in that page.
|
|
|
|
|
It seems you are hell-bent on finding a "fix" for this. Did you consider the possibility that you've been exploiting a bug in the .NET Framework and that bug has now been fixed under .NET 4.0?
I can't find a hotfix, for either Visual Studio 2010 or .NET 4.0, for this problem anywhere, other than change your code.
|
|
|
|
|
Nope This problem only occurs when using visual studio 2010 even when setting the project back to 3.5 does not fix it. But nice theory.
Again only occurs when debugging if compiled and running outside of debug mode the program runs beautifully, i can live with it but i sure am gonna miss stepping through code
Chona1171
Web Developer (C#), Silverlight
|
|
|
|
|
You might have to do some searching on the internet.
There might be something in your code that causes this error to occur.
I found a couple of threads where such issues have been discussed.
One was this[^] and the other was with lambda expressions.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
|
|
|
|
|
you mentioned that you upgraded from VS 2008 .Net 3.5 to VS 2010 .Net 4.0 and that the problem is in some COM code.
Go back and check your reference assemblies. Many reference assemblies have different .dll versions for 3.5 versus 4.0. Be sure you are using the updated assembly.
Good luck.
Robert Tanenbaum
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
