|
Paper clip: I see you are creating a transister radio; would you like some help with that?
|
|
|
|
|
*grin* NOW you're talking.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
PIEBALDconsult wrote: Paper clip
*shotgun* BANG, oh damn another screen gone......
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hi,
if shooting monitors is a habit of yours, you should consider buying those new OLED ones.
They are organic, so given the right amount of nutrients and water may make them recover from modest shot wounds.
|
|
|
|
|
much cheaper to banish clippy to the pits of hell....
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
That won't cut it, if you dismiss Clippy then Rocky or one of his friends will haunt you.
|
|
|
|
|
thanks I will give it a go. Does anyone know of any code that i can work from?
|
|
|
|
|
The code below is for a button which saves the details on a form to the xml file. What I'm trying to do is get it so that:
a)It has a "Save" option
b)It also hase a "Save as" and creates a new file(name etc)
but, for the life of me i cant see what i'm doing wrong
private void button1_Click(object sender, EventArgs e)
{
if (openFileDialog1.FileName.Length > 0)
{
string path = openFileDialog1.FileName;
FileStream READER = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);
System.Xml.XmlDocument CharDetail = new System.Xml.XmlDocument();
CharDetail.Load(READER);
System.Xml.XmlNodeList NodeList = CharDetail.GetElementsByTagName("Character");
NodeList[0].FirstChild.ChildNodes[0].InnerText = CharName.Text;
NodeList[0].FirstChild.ChildNodes[1].InnerText = Virtue.Text;
NodeList[0].FirstChild.ChildNodes[2].InnerText = Vice.Text;
FileStream WRITER = new FileStream(path, FileMode.Create, FileAccess.Write, FileShare.ReadWrite);
CharDetail.Save(WRITER);
}
}
This is the code for the SAVE function(eg overwrites the current file)..i'm trying to add a SAVE AS functionality to it
Now I know that the SaveFileDialog box should be used but where/how would i intergrate it?
|
|
|
|
|
System.Xml.XmlDocument.Save method does not take any FileStream as its parameter. So CharDetail.Save(WRITER); throws an exception. You can pass a string as your Xml file path to this method.
For Save As... your path will be the saveFileDialog's FileName property.
[Edit] Oops... My apologize... You can pass a FileStream as parameter since it's a Stream
I died as a mineral and became a plant,
I died as plant and rose to animal,
I died as animal and I was Man.
Why should I fear? When was I less by dying?
-- Rumi[^]
My blog
modified on Wednesday, November 26, 2008 3:27 PM
|
|
|
|
|
so is this what ya mean
string path2 = SFD.Filename;
FileStream WRITER = new FileStream(path2, FileMode.Create, FileAccess.Write, FileShare.ReadWrite);
CharDetail.Save(WRITER);
and that would create the new file? or am i missing something? (tis late and long dy at work so please treat me like the simpleton i am :-p)
|
|
|
|
|
Hi,
the difference between Save and Save As is that Save saves to a known location without any dialog (e.g. the result of an earlier OpenFileDialog OR an earlier SaveFileDialog), and Save As saves to an explicitly chosen location (e.g. the result of an instantaneous SaveFileDialog).
In all cases, the actual writing code is the same, it is only the path that differs. (In your case the first parameter of the FileStream constructor).
|
|
|
|
|
ok will give that a go later . Thanks
|
|
|
|
|
Yup, that exactly create a new file (assume you filtered SFD to *.xml).
I died as a mineral and became a plant,
I died as plant and rose to animal,
I died as animal and I was Man.
Why should I fear? When was I less by dying?
-- Rumi[^]
My blog
|
|
|
|
|
Chris Kentlea wrote: This is the code for the SAVE function(eg overwrites the current file)..i'm trying to add a SAVE AS functionality to it
The obvious way to do this is to factor out a save method that takes a path, then either show a dialog box to select a path and pass it along, or pass on the existing path, in the two event handlers.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
So I have some sample code, it works fine.
using System;
using System.Threading;
using System.IO;
namespace whatever
{
class t
{
public static TextWriter tw = new StreamWriter("date3.txt");
static void Main()
{
Thread firstThread = new Thread(new ThreadStart(Fun1));
Thread secondThread = new Thread(new ThreadStart(Fun2));
firstThread.Start();
secondThread.Start();
tw.WriteLine("End of Main()");
}
public static void Fun1()
{
for(int i=1; i<=500;i++)
{
tw.WriteLine("Fun1() writes: {0}",i);
}
}
public static void Fun2()
{
for (int i=0; i>= -200; i--)
{
tw.WriteLine("Fun2() writes: {0}",i);
}
}
}
}
From my understanding from what I've read, both firstThread and secondThread should be executed simultaniously, but my output shows that thread one finishes (outputs 0-500), then "End of Main()", followed by the output of Fun2 (0-200).
Shouldn't it have been mixed in there (the output from Fun1 and Fun2), or is each thread executed after the previous terminates?
|
|
|
|
|
Similar results here, although sometimes I get this:
Probable I/O race condition detected while copying memory. The I/O package is not thread safe by default. In multithreaded applications, a stream must be accessed in a thread-safe way, such as a thread-safe wrapper returned by TextReader's or TextWriter's Synchronized methods. This also applies to classes like StreamWriter and StreamReader.
I think it's just a case of the time taken to create the thread is longer than it takes to execute Fun1(). Change it from 500 to 5000000 and -200 to -2000000 and you'll get your interleaving - or would if it was threadsafe of course.
Regards,
Rob Philpott.
|
|
|
|
|
Ahh thanks, I first ran it with extremely small numbers (0 to 10, 0 to -10) and thought my 500/-200 changes would allow me to have the overlapping results I was testing for. Going to try now and if it works, I guess the error on my part is assuming the speed of threads to be higher/ slower then I expected.
Next time I'll test more thoroughly before posting.
Thanks again
|
|
|
|
|
EliottA wrote: Ahh thanks, I first ran it with extremely small numbers (0 to 10, 0 to -10) and thought my 500/-200 changes would allow me to have the overlapping results I was testing for. Going to try now and if it works, I guess the error on my part is assuming the speed of threads to be higher/ slower then I expected.
In non realtime OSes the overhead involved in swapping threads is high enough that they generally get several milliseconds at a minimum before being swapped out. Realtime OSes can do the swap much faster, and have significantly smaller time slices as a result, but have their own limitations due to the architectural changes needed to support the fast switching.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
A follow up:
500000/-200000 worked and I had overlapping results.
Thanks for the help.
|
|
|
|
|
EliottA wrote: From my understanding from what I've read
Read where?
EliottA wrote: both firstThread and secondThread should be executed simultaniously
I don't know where you got that from, but that contradicts what I know about using multiple threads. Without knowing what you read, I can only guess that either your source is incorrect or you did not understand it correctly.
led mike
|
|
|
|
|
|
led mike wrote:
ElliotA wrote: both firstThread and secondThread should be executed simultaniously
I don't know where you got that from, but that contradicts what I know about using multiple threads. Without knowing what you read, I can only guess that either your source is incorrect or you did not understand it correctly.
The threads can run concurrently on a multithreaded system. Only on a single core non HT system is sequential/interleaved behavior guaranteed.
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
Hi,
on a single core without hyperthreading the CPU will be used by one thread until it runs out of a job, or something really significant occurs that makes the OS decide to switch threads; threads are not switching all the time, it is just too expensive.
You could add a random delay (with Thread.Sleep) to one or both of your threads; and then you could set one of them at a "below normal" priority, to make things more interesting (make sure the highest priority one has reasons not to finish in one stint).
As soon as hyperthreading or multi-core hardware is involved, two or more threads may really run at the same time, until or unless they get synchronized somehow. Both of them using the same TextWriter will synchronize them: the class has to do something to prevent characters of multiple lines (from different threads) getting intertwined.
Another experiment would be:
have one integer counter as class members.
thread1 increments counter and stores value of counter in a List<int>
thread2 decrements counter and stores value of counter in another List<int>
Don't call any I/O in those threads, don't create a possible synchronization point, just let them try to get 100% of the CPU cycles.
After some time, stop both threads and list (part of) one or both Lists.
Without multicore/HT the lists will be monotonous for a long time (say 16 msec); with MC/HT they ideally would oscillate around zero assuming identical code in both threads, and they would evolve "slowly" if one of the threads wastes some cycles with respect to the other (by adding some statements that don't get optimized away).
|
|
|
|
|
So if I am not running on a multithreaded processor, ad you are saying each thread will be executed in order that they are started, why bother creating multiple threads at all??? Where is the gain? Wow Now you guys just made me have 1000 questions, which I am sure 999 will be stupid.
|
|
|
|
|
Hi,
Basically multi-threading is to an app, what multitasking is to a system.
So the potential gain is twofold:
1.
as soon as one thread can not continue (e.g. pending I/O) instead of the CPU becoming idle (assuming only one app is present), another thread will take over, hence the total app's elapsed time CAN be much less than when you do everything sequentially on a single thread.
2.
your app MAY be much simpler to write in a multi-threaded way: you might ignore how the events in different threads will occur in real-time, and get away with it. In a single thread things are bound t occur in the order they were programmed in code, which may or may not be an accurate representation of the outside world.
However, thread synchronization may be a concern, if you don't synchronize, results may be wrong; and if you don't synchronize correctly, deadlocks may occur, causing your app to hang.
|
|
|
|