|
Hi Navaneeth,
DoTask is doing its work asynchronously, that is it returns immediately after creating a thread. Can anyone answer my question that event invoking is done in the caller or done/called at a later time by the CLR?
Thanks!
|
|
|
|
|
Hi,
in order to execute multiple tasks sequentially I prefer using a Queue.
With a queue, there is no recursion, it boils down to a simple loop:
while(there is work to do) do it;
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:16 PM
|
|
|
|
|
DoTask is a asynchronous task, it spawn a thread to do its stuff and return immediately. It is not sure when it is finished. The completion of the task is notified though OnTaskComplete.
|
|
|
|
|
Wong Shao Voon wrote: DoTask is a asynchronous task, it spawn a thread to do its stuff and return immediately
That doesn't make any difference. You still can use a queue and execute the jobs from the queue. If the queue is empty consider all the job done. You can make this queue accessible to all the threads so that other threads can enqueue new tasks.
|
|
|
|
|
right.
just make sure to provide some synchronization (say a lock) so the queue doesn't get messed up.
Luc Pattyn [Forum Guidelines] [My Articles]
I use ListBoxes for line-oriented text output (not TextBoxes), and PictureBoxes for pictures (not drawings).
modified on Friday, June 10, 2011 12:17 PM
|
|
|
|
|
That's correct
|
|
|
|
|
Wong Shao Voon wrote: Is event calling done in the caller or it is dispatched to be done at a later time?
Event firing is synchronous i.e. performed on the thread that fires the event.
However, if DoTask is asynchronous, then it will run on a different thread and therefore you won't get into infinite recursion.
DoTask -> TaskCompleted -> OnTaskCompleted -> Method End
|-> DoTask -> TaskCompleted ....
|
|
|
|
|
Hi
There is a peculiar requirement of copying in clipboard data as an OLE object into a RichTextBox.
I am using the clipboard object to retrieve the contents in an rtf format.
this.richTextBox1.SelectedRtf = Clipboard.GetData(System.Windows.Forms.DataFormats.Rtf).ToString();
Is it possible to copy the clipboard data as OLE object rather than an rtf.
Regards
Gaurav
|
|
|
|
|
Found this[^] here on CodeProject.
Enjoy
I are troll
|
|
|
|
|
how should i implement
**a
in c# equivalent
the quieter u become more u hear
|
|
|
|
|
I'd suggest to take a good C# book and work with it.
|
|
|
|
|
bool HMM::readHMM(FILE *fp)
the above code is vc++..
wat is the equivalent in c#
the quieter u become more u hear
|
|
|
|
|
lawrenceinba wrote: wat is the equivalent in c#
There is no equivalent in C#. Create the class HMM and add readHMM as a static method. System.IO.File class can be used to work with files, but since it is a static class, you can't pass the instance.
|
|
|
|
|
I've got a boolean IsDirty property on my object Foo. When a change happens on my object I set IsDirty to true. Later when I go to save my object I check IsDirty and it is set to false.  
I've set breakpoints both on the Set and the Get for my property. The only time the value is set is when I set it to true. Yet after it's set to true when I try to read the value it comes back as false. The only place my variable mIsDirty is used is in my IsDirty property Get and Set.
I've tried renaming and re-creating the property but the problem remains. Something has got to be changing my property but the the breakpoint on my Set is never hit and I'm not using mIsDirty elsewhere. I've never had a boolean property misbehave before. This is driving me insane.
Has anyone else ever encountered a problem like this or have a suggestion on how to debug it?
My code for the property is setup as follows:
private bool mIsDirty;
internal bool IsDirty
{
get
{
return mIsDirty;
}
set
{
mIsDirty = value;
}
}
|
|
|
|
|
Add this.text = misdirty to the setter
Then keep an eye on the form text, may help when the value changes if not why.
Why not use an auto property and eliminate misdirty altogether (then there is NO chance it will be set somewhere).
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I did give that a shot and had the same results. Something somewhere seems hellbent on changing that property without notifying me that it's doing so.
I've rebooted and done everything else I can think of. I'm about to just delete class/file and start fresh. 
|
|
|
|
|
My first suspicion is that the get and set operations are using different objects.
So check the object to determine if they are the same.
«_Superman_»
|
|
|
|
|
The object isn't being serialised and deserialised somewhere, is it?
Are you are saying that, when debugging, immediately after the line mIsDirty = value; is executed, with value = true, the variable mIsDirty has a value of false?
If so, then I would suggest your debugger has got itself in a knot - it can happen. Exit VS and clean solution before trying again...
If I knew then what I know today, then I'd know the same now as I did then - then what would be the point?
.\\axxx
(That's an 'M')
|
|
|
|
|
Not serializing anything in this code. I've tried rebooting and cleaning.
It's the weirdest thing. In the property set I can watch the incoming value set my mIsDirty variable. Once that's been done the next call to get Foo.IsDirty returns false.
I've never run into anything like this before. Think I'm just going to delete the class/file and start fresh.
|
|
|
|
|
thrakazog wrote: the property set I can watch the incoming value set my mIsDirty variable. Once that's been done the next call to get Foo.IsDirty returns false.
But immediately after the Foo.isDirty - true; what is the value of misDirty - i.e. is it EVER getting changed to true?
If it is getting changed to true, then you need to track down where it is getting set to false again - if it is not then you need to find out why.
My suspicion from what you have said would be that the Foo.Isdirty you are SETTING is a DIFFERENT instane to the Foo you are GETting.
try setting the value of mIsDirty to true by default (i.e. private bool misDirty = true;) my guess is that your code will then return true regardless as to what you set it to - because you are 'reading' a different variable to that which you are writing'
as other posters have said, it's probably not best practice to set the property externally tot eh object - better to have it as a read-only property which teh oject sets itself each time another propery is changed. Where child objects implement a similar functionality (hopefully they ll inherit from some base object, or implement a common interface) they could rais an event (sort of an 'ImNowDirty' event, if you like) which other objects can handle - so the parent handles the child event, and sets its IsDirty appropriately
Finally - whatever happens - please reply here when you solve it - I'm intrigued as to teh cause!
Good Luck!
If I knew then what I know today, then I'd know the same now as I did then - then what would be the point?
.\\axxx
(That's an 'M')
|
|
|
|
|
I've changed how I was handeling the IsDirty notificaiton and the problem has gone away. My best guess is that I had a few objects that were setting this property fighting over what the value should be. Under normal circumstances this would be easy to detect, but for some reason my debugger wasn't stopping in my Set statement when it was being called from these other objects. I even setup some debug.writeline statements in my set that said: "Being Set True", "Being set false". As soon as I would set Foo.IsDirty = true I would see:
Being Set True
Being set false
in the immediate window. So something was running right along behind me setting the value back to false and ignoring my break points as it did so. I could have probably resolved this issue in a few minutes if my breakpoint was being hit each time the value changed.
I've never even heard of anybody experiencing this problem before. I certantly hope I never get to experience it again. 
thanks.
|
|
|
|
|
Not sure what the problem could be, however, you should not be allowing another object to set the isDirty property--bad design. A better idea is for the object to decide when it is dirty and the property should be readonly. In your design your object might not be dirty and another object can easily set it to dirty and then "Houston, we have a problem!". So do the following:
public string Name
{
get
{
return _name;
}
set
{
_name = value;
// Now I am dirty since I am changed so I will set myself as dirty since I am a smart object
_isDirty = true;
}
}
|
|
|
|
|
CodingYoshi wrote: allowing another object to set the isDirty property--bad design.
Yeah, this problem is making me question my current design all right. The way I have it right now the property can be changed from my Foo object when one of it's properties like name changes. Foo however has children objects that can also be dirty. If a child is dirty I have it mark Foo as dirty so I don't have to go searching the whole child hierarchy each time I check the property.
grumble..........
|
|
|
|
|
You have a good attitude and will go far in life! Especially if this is the kind of attitude you have when you are clearly asking for help and someone used their valuable time to help you out. BTW it is still a bad design and there is a better solution but I doubt you will get it with that attitude.
|
|
|
|
|
CodingYoshi wrote: I doubt you will get it with that attitude.
This problem has me frazzled but I wasn't trying to give any attitude. My apologies if that's how I came off.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
