|
you are right, some people may put more than one namespace in a file, I know I wouldn't.
BTW: it is much too early to tell, preliminary battles yielded a typical 50%, however it is a 9-day open encounter according to the Swiss[^] pairing system.
|
|
|
|
|
Luc Pattyn wrote: some people may put more than one namespace in a file
Yeuch! No, no, no! Don't do it!
One class, one file.
One namespace, many files.
Internal is not restricted to file, just to namespace.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
|
Assembly AND namespace. You cannot use someone else's internal classes by simply adding your own version of that namespace in your own assembly. The whole idea is to make it so that ONLY the guy who wrote the original method can decide how to use it. Not so that only people who know what namespace it is can use it. This is basic .net 101, and has been true since version 1.0.
edit: one more qualification, this applies to 'internal' classes that do not specify the 'internal' modifier. If you specify the 'internal' modifier you can use them within any namespace as long as you reference the correct one, but STILL only within the original assembly. So for example a class declared as
class MyClass(){ } can only be referenced in its original namespace and assembly.
However, one declared as
internal class MyClass() { } can be referenced by anything in the assembly.
|
|
|
|
|
Hang on, I've just realised - by file you are referring to Assembly (DLL/EXE) where I am referring to source. Oops!
But I agree - one assembly, one namespace.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
you should have left it at that.
I did say source file, not assembly.
|
|
|
|
|
Internal class is visible only inside assembly. You can use it to implement functionality, that is required by your assembly, but shouldn't be accessible outside the assembly.
The real life example you say...
Let's say your application has an assembly for accessing database. You have classes with methods that perform some operations on database (insert, update, delete, select). Under the hood you use Entity Framework, but to assure, that database access is performed only with your classes, you set Entity Framework context class as internal. That provides you with cleaner code and strict separation of layers - higher layers don't know what mechanism you use for accessing database... and honestly, they shouldn't care.
Don't forget to rate answer, that helped you. It will allow other people find their answers faster.
|
|
|
|
|
If someone has a better idea in how I can do this please let me know. Normally I what I would do is call sqlreader and each field I would put into a custom array to use through out the application.
Well now that I have learned how to create a dataset, while in code without using the vs customized dataset's interface...
string connectionString = TheSQLConnectionString.ConnectionString.ToString();
using (connection = CreateConn())
{
command = new SqlCommand(TheSQLCommand, connection);
SqlDataAdapter adapter = new SqlDataAdapter(command);
adapter.Fill(dtSet);
}
Now what I want to be able to do is take the (dtSet) dataset and in code read each row and each row's columns of data.
However I want to place this code in a class Passing the parameters (table, row, and column) and I want the class procedure to return the value.
Can someone point me in the right direction please in how to understand datasets in order to accomplish this?
Thanks in advance.
|
|
|
|
|
If you don't actually want the DataSet, then don't create the DataSet.
I prefer to just use a DataReader and directly populate the classes I intend to use.
DataAdapters, DataSets, and DataGrid(View)s weren't created for actual real-world use -- their only purpose is allow MS demonstrators to quickly create barely-useful applications to make easily-impressed audiences go "ooohhh".
|
|
|
|
|
PIEBALDconsult wrote: DataAdapters, DataSets, and DataGrid(View)s weren't created for actual real-world use -- their only purpose is allow MS demonstrators to quickly create barely-useful applications to make easily-impressed audiences go "ooohhh".
10+
I bug
|
|
|
|
|
Ok how do you recommend getting the data from sql server database into the application if you do not recommend the use of datasets?
|
|
|
|
|
that question has been answered here already.
|
|
|
|
|
Motion Seconded, on all points.
ragnaroknrol The Internet is For Porn[^]
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
Cynical, definately cynical.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
So, it's been a while since I did any threading and so I thought to review some BackgroundWorkers.
I made a test program and get this exception I cannot explain.
It occurs during the ProgressChanged event when reading a double value.
I'm using an ArrayList as argument where the first value is a double (for accurate progress report) and the second value is a string array.
The exception gets thrown when trying to assign the value of the ArrayList to a local double variable.
Can anyone tell me what went wrong and how I can fix it?
private void BW_Text_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
ArrayList arg = (ArrayList)e.UserState;
double progress = (double)arg[0];
string[] content = (string[])arg[1];
textprogress += progress;
TSL_Text.Text = "Status: Reading..." + String.Format("{0:0.##}", textprogress) + "%";
Fill_ListView(true, content);
}Thanks!
|
|
|
|
|
Rather than just casting the UserState to an ArrayList, check it: use is or as and make sure it is what you think it is - a UserState could in theory be any Object, so it is well worth checking. I would use as as I like to see explicit null checks.
Do the same with the content of the ArrayList: check is is a double.
Since you don't say what the exception is, it could be caused by either; but check both - it doesn't add a lot of overhead and it makes your program a lot more robust.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I told you what the exception is, VS doesn't give any further explanation (which is why I'm so confused).
The code that throws it (according to VS) is the Application.Run line in the program class.
Though seemingly I was able to get rid of it by properly checking the userstate and always sending new ArrayList.
On the other hand, ReportProgress seems sorta broken. It happens once every blue moon compared to the DoWork event.
In DoWork I'm running a loop and part of it is the ReportProgress method, yet the first time the event is actually raised happens between randomly the 350th and 400th time of the loop.
How come?
When debugging I set break points in the DoWork and ReportProgress events and confirmed that DoWork is only actually raised after DoWork looped several times.
|
|
|
|
|
Megidolaon wrote: In DoWork I'm running a loop and part of it is the ReportProgress method, yet the first time the event is actually raised happens between randomly the 350th and 400th time of the loop.
That is perfectly feasible as the ReportProgress method raises the ProgressChanged event asynchronously. Presumably by the time the UI thread gets around to processing the first event the BackgroundWorker has called ReportProgress 350-400 times and quite a backlog has built up. If each ProgressChangedEventArgs references the same ArrayList then you will always see the most recent values and not those that were in force at the time the event was raised.
As a guess your code should not raise the event more frequently than once every 1000 loop iterations. Even that will probably be far too frequent and you should aim for no more than 2 per second if a display element is being updated.
Alan.
|
|
|
|
|
Thanks.
I guess I should better collect the data within the DoWork event and then report a while bunch at once.
But now the TargetInvocationException is back and I can#t find it, no matter where I set a breakpoint.
modified on Monday, August 16, 2010 9:47 PM
|
|
|
|
|
In the debugger, check to be sure the actual values are what you expect.
But, personally, I wouldn't use the ArrayList, I'd make separate fields in the ProgressChangedEventArgs.
|
|
|
|
|
Three remarks FYI:
1.
there is ProgressChangedEventArgs.ProgressPercentage which is of type int; its name suggests the value should be in the range [0,100] however the value is irrelevant to .NET and you can pass any value you choose, from int.MinValue to int.MaxValue, so you have a full 32-bit resolution at your disposal.
2.
I don't expect people be interested in a very accurate progress value; if you were to display a progress bar on a display with say 1280 pixels, then you would be able to show no more than 1281 different values anyway; yes you could just show a number, but that does seem a bit awkward.
3.
Once you have settled on the exact range and resolution you want to pass around, you should make sure not to call ReportProgress() with the same progress value over and over, as each call causes a thread switch, and achieves nothing as no new information is passed anyway. So create a little method and compare with the previous value, as in:
public void MyReportProgress(int val) {
if (val!=previousVal) {
previousVal=val;
ReportProgress(val);
}
}
You may be surprised how much faster your actual operation runs once you stop passing unnecessary progress resolution back and forth (and stop repainting that progress bar abundantly).
|
|
|
|
|
Hi
I'm working on an client/server application which uses the UdpClient class to communicate over a network. The server end waits for a datagram to be received, after which it then processes the datagram and sends back a response. To stop the code from blocking, I am using Udpclient.BeginReceive and doing it all asynchronously. The BeginReceive method takes a delegate as its argument, which points to the method which processes the data (the callback method). What I need to know is whether the callback method runs in a separate thread? As usual the documentation is useless.
Thanks
modified on Sunday, August 15, 2010 11:35 AM
|
|
|
|
|
The callback method runs in a separate thread obtained from the thread pool.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
