|
Hi,
I'm studing VS 2005 C# XPRESS Ed. and I'm facing with reporting. It seems Crystal Report isn't available for VS XPRESS Ed., is it? Can someone help me? I need to import some library into my c# prj (CrystalDecisions.*) but I don't know how to provide them...
Thanks in advance
|
|
|
|
|
*shameless self-plug*
See sig 
----------------------------
Be excellent to each other
EasiReports[^] My free reporting component for WinForms.
|
|
|
|
|
Good Afternoon,
I've kinda hit a brickwall today with something I thought would be pretty straight forward. I have a form that loads after checking user's login credentials. I have all the "processing" functions in an independant class that I use often in other projects. The objects on the form are set to public. I understand that a c# form is a class so I thought the following would work but I can't seem to get access to manipulate the objects on the form.
DataGridView dgCallMonitor = (DataGridView)frmOpsCon.ActiveForm.Controls["dgCallMonitor"];
Any help or pointer to what I'm doing wrong would be appreciated
JB
|
|
|
|
|
What I usually do in a case like that is make a public property on the form in question exposing the control then I can just access it through the property.
|
|
|
|
|
An alternative to exposing the form controls to the "processing" class, which would encumber it with the overheads of Windows.Forms etc, is to use delegate methods. See my post to the nearby question from teejayem titled "Dll question". I've used this method in classes that are used in three environments gui, command line and server, works well.
cheers phild
|
|
|
|
|
Hello,
Is it necessary to ensure thread-safety for an instance of the System.String class? I understand that Strings are immutable types, but I was unsure if this necessarily means that an instance of the System.String class is thread-safe for multiple readers and multiple writers.
In my application, several Strings which belong to an instance of a class will be both accessed and changed from multiple threads. I can easily put a lock on them and make sure the operations do not clash, but if I do not have to waste time waiting for the lock because the type is naturally thread-safe then of course I do not want to.
I understand that this may be a simple question, but for some reason I cannot find a clear universal answer to the question.
Thanks in advance!
Sincerely,
Alexander Wiseman
|
|
|
|
|
They are not threadsafe by default. Only static variables are automatically threadsafe.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Thanks for your reply. I am still confused, however, because in the MSDN documentation, it says this about a System.String (and it makes no distinction between static members and instance members):
Quote from MSDN System.String Overview
Thread Safety
This type is safe for multithreaded operations.
End quote from MSDN
Furthermore, just because a variable is declared to be static does not mean that it is thread safe. I was under the impression that the programmer had to make sure that variables, even static ones, were thread safe.
That being said, my original confusion remains, because it seems like, from the MSDN documentation, there is nothing required on the part of the user of the System.String class to ensure thread safety. What little I have read concerning "immutability" of the string type would support this. On the other hand, if I am doing multiple write operations and multiple read operations, is there going to be a problem?
Thanks again.
Sincerely,
Alexander Wiseman
|
|
|
|
|
Alexander Wiseman wrote: That being said, my original confusion remains, because it seems like, from the MSDN documentation, there is nothing required on the part of the user of the System.String class to ensure thread safety. What little I have read concerning "immutability" of the string type would support this. On the other hand, if I am doing multiple write operations and multiple read operations, is there going to be a problem?
Since strings are immutable, they are thread safe. What happens when you perform a write operation on a string is that a new string is created as a result; the original string remains unchanged.
|
|
|
|
|
Thanks for your reply.
Let me just make sure I have this clear with a quick example. Let us say that I have two threads, A and B, both of which have access to String someStr = "My String".
Now let's say that the processor gives a time-slice to thread A, which then reads the string. Then the processor gives a time-slice to thread B, which then changes the string from "My String" to "Your String".
If I understand you correctly, then because strings are immutable, no matter when the processor decides to temporarily stop processing on thread A, nevertheless thread A will still see the value "My String", even though thread B may have "changed" it already. Is that correct?
Thanks again for your help!
Sincerely,
Alexander Wiseman
-- modified at 17:48 Tuesday 13th June, 2006
[EDIT]
Just read another poster's reply, which answers this scenario in the affirmative.
[/EDIT]
|
|
|
|
|
Alexander Wiseman wrote: Let me just make sure I have this clear with a quick example. Let us say that I have two threads, A and B, both of which have access to String someStr = "My String".
Now let's say that the processor gives a time-slice to thread A, which then reads the string. Then the processor gives a time-slice to thread B, which then changes the string from "My String" to "Your String".
If I understand you correctly, then because strings are immutable, no matter when the processor decides to temporarily stop processing on thread A, nevertheless thread A will still see the value "My String", even though thread B may have "changed" it already. Is that correct?
What you're doing here isn't changing the string. You are changing the reference to the string. When you do this:
string someString = "My String";
And then do this:
someString = "Your String";
You've taken the reference to "My String" and changed it to point (sorry for the C++ nomenclature) to "Your String";
That's not the same as actually changing the string. And as far as I know, changing what a reference, erm, references is not an intrinsically thread safe operation, but I could be wrong.
Changing the actual string would be doing something like this:
string someString = "My String";
someString.Concatenate(" and Your String");
Console.WriteLine(someString);
Now, the above code isn't possible with an immutable string. Rather the operation for concatenating a string creates a new string:
string someString = "My String";
string anotherString = someString.Concatenate(" and Your String");
Console.WriteLine(someString);
Console.WriteLine(anotherString);
Again, I'm not sure if the string class actually has a "Concatenate" method, but the principle is the same. When doing a write operation on a string, a new string is created as a result leaving the original unchanged.
[EDIT]Apparently, changing what an object references is an atomic operation, so it is thread safe.[/EDIT]
-- modified at 18:00 Tuesday 13th June, 2006
|
|
|
|
|
Alexander Wiseman wrote: In my application, several Strings which belong to an instance of a class will be both accessed and changed from multiple threads. I can easily put a lock on them and make sure the operations do not clash, but if I do not have to waste time waiting for the lock because the type is naturally thread-safe then of course I do not want to.
When you say that the strings belong to an instance of a class and are accessed and changed, are you talking about string properties?
-- modified at 17:44 Tuesday 13th June, 2006
|
|
|
|
|
Thanks for your help, Leslie. Actually I think the question was simpler than that - Guffa's post below answers it.
Sincerely,
Alexander Wiseman
|
|
|
|
|
As strings are immutable, you can't change a string. What happens when you assign a new value to a string variable, is that the new value is a separate string object, and the reference to that object replaces the reference to the previous value.
As reading and writing references are atomic, there is no need to use a lock.
When you read the string value, you are copying the reference to the string. You can then use that reference to access the string that was the value at the moment you read the reference, without fear of anything happening to that string.
---
b { font-weight: normal; }
|
|
|
|
|
Thanks for your reply Guffa. That makes perfect sense! I think the thing that I was missing was that reading and writing references are atomic.
Sincerely,
Alexander Wiseman
|
|
|
|
|
Guffa wrote: As reading and writing references are atomic, there is no need to use a lock.
Oh, that's good to know! I had guessed that it wasn't but glad to learn that I was wrong.
|
|
|
|
|
The original post was correct strings are immutable and therefore threadsafe.
|
|
|
|
|
It's kind of misleading though. For instance:
if(someVolatileVariable != null)
{
someVolatileVariable.DoSomething();
}
That is buggy multithreaded code! The reason is that another thread could potentially set someVolatileVariable to null after the current thread checks whether it is not null. A correct version of that would be:
Foo someVar = someVolatileVariable;
if(someVar != null)
{
someVar.DoSomething();
}
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Goof around music jam with my brothers (with video)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
Good point. Events work the same way:
Bad:
if(WorkCompleted != null)
{
WorkCompleted(this, EventArgs.Empty);
}
Good:
EventHandler handler = WorkCompleted;
if(handler != null)
{
handler(this, EventArgs.Empty);
}
|
|
|
|
|
Reading and writing references may be atomic, but that doesn't solve much; a thread may need to read a variable, but may be seeing old/dirty data depending on the processor architecture. That's why we have methods like Thread.VolatileRead, Thread.VolatileWrite, and the volatile keyword.
Tech, life, family, faith: Give me a visit.
I'm currently blogging about: Goof around music jam with my brothers (with video)
The apostle Paul, modernly speaking: Epistles of Paul
Judah Himango
|
|
|
|
|
I have an unusual situation where I have about 30 classes that have huge swaths of source code that is identical to each class.
Unfortunately about 30 % is unique to each class and I can't just take the similar bits and make a new class out of them because it's a big struct and method to fill that struct from a database (they are IList based class that feeds a read only datagrid and is used for reporting)
What I'm currently doing is copying and pasting but this is tedious and what I'd really like to do is define the chunks of code that are common and have the compiler insert them into the classes on compiling. AFAIK this isn't a feature in visual studio 2k5 or c#.
Does anyone have any ideas or suggestions?
|
|
|
|
|
Could you break out the parts that are repeated and put them into a base class that all of your other classes will derive from?
|
|
|
|
|
No unfortunately, the common code is inside a struct and the different part is inside the same struct.
|
|
|
|
|
Does it need to be a struct?
---
b { font-weight: normal; }
|
|
|
|
|
yes absolutely, it's business objects in released software production code, there is a huge system revolving around it for reporting, displying in grids and filtering and sorting, matching up sql column names and localized text keys to public properties in the struct, binding it to reports and grids etc etc and to top it all off I'm over 300 of them now so absolutely no possibility of doing it any differently at this point, on top of which it's the best way to do it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
