|
table.clear()?
table = null?
table.remove?
|
|
|
|
|
DataSet.Tables["TableName"].remove()
|
|
|
|
|
Well if you have a bad design, you have to work around it. You should never have tables with the same name.
|
|
|
|
|
Ok so you have an xml specification which has a value called ID. These are attributes of an http table not a dataset.table although they can be the same.
If you are talking about tables in a dataset they should match a good relational model. Each table has a different name, each row in the table should have a unique identifier. No different in this case with what you showed, although it looks like you don't have a unique id.
I am not totally familar with sending a dataset to an xml file, but it is supposed to keep all of the design (schema). It should work exactly the same in reverse.
Try this, create a dataset with a table from scratch, then save it off as a xml file, open the file in a regular editor and see what it wrote out there. Then modify your table above to match that schema. (If you can). Otherwise you will have to pull data out of each of the tables above and decide what datarows you want to delete.
|
|
|
|
|
Ok so you know which appointments need to be deleted right?
Let's try to map a design out for this.
You have existing data and new data right?
You want to compare existing to new.
For outdated entries you want to delete the calendar entry?
This sounds like a bridge pattern. But I'd have to check that out.
|
|
|
|
|
Is there a way to cancel\throw error when a user try to use = in my collection without using any methods?
eg.:
<br />
MyCollection myCol = new MyCollection();<br />
myCol.Add(new ObjectInstance());<br />
myCol[0] = new ObjectInstance();
Please help.
Thanks.
NaNg.
|
|
|
|
|
Just make your indexer property get only with no set .
Logifusion[^]
|
|
|
|
|
Thanks, forgot about that.
|
|
|
|
|
I am using the invoke() to call a delegate in order to communicate with another form in a different thread. The code is below.
<br />
<br />
You can see at the bottom (before the stars) where the thread is started. The method below that is being called by the delegate in the code below the stars. Each set of code is in a diff thread.<br />
<br />
public class MainForm : System.Windows.Forms.Form<br />
{<br />
private void search()<br />
{<br />
<br />
Search ArtifactSearch = new ArtifactSearch(this);<br />
<br />
ArtifactSearch.SearchComplete += new Search.ProcessingCompleteDelegate(Search_ProcessingComplete);<br />
<br />
Thread StegSearch = new Thread(new ThreadStart(ArtifactSearch.Start));<br />
<br />
StegSearch.Start();<br />
}<br />
<br />
private void Search_ProcessingComplete()<br />
{<br />
}<br />
<br />
*********************************************************************************************<br />
<br />
public class Search<br />
{<br />
MainForm Parent;<br />
<br />
public event ProcessingCompleteDelegate SearchComplete;<br />
<br />
public Search(MainForm parent)<br />
{<br />
Parent = parent;<br />
}<br />
<br />
public void Start()<br />
{<br />
<br />
Parent.Invoke(SearchComplete,null);<br />
}<br />
}<br />
My problem is that when i invoke the SearchComplete delegate it tells me that "SearchComplete" is not set to an instance of an object. But as you can see it clearly is set to a new instance before the thread is started. How do I fix this. I have used delegates in this manner in other areas of my code and it worked. I'm stumped.
|
|
|
|
|
Not that I'm a threading expert or anything, but I've run into a similar problem before. Is there any place in your code where you are releasing the event? I'm thinking that maybe you should put a lock statement in there somewhere - it seems likely that you are removing the handler for the event before you actually call it (possibly on another thread).
Also, I'm not sure if this is an issue or not, but can you try moving the declaration for the ArtifactSearch object up to the class level. I'm wondering if there might be a scoping issue here that we aren't seeing.
Will
|
|
|
|
|
I'm not familiar with lock statements or releasing events. How do you use the lock statement?
|
|
|
|
|
Actually, after looking it over in light of my other comments, I'm not sure it's needed. Just raise the event and catch it on your form. Then, if InvokeRequired is true, you'll need to call Invoke. I would do this from the form instead of your class, as doing otherwise entangles the two objects. You could have the following, for instance:
public void Search_ProcessingComplete()
{
if(this.InvokeRequired)
{
this.Invoke(Search_ProcessingComplete);
}
else
{
//Do your stuff here that hits the UI.
}
}
On your Search object, your Search method would look like:
public void Start()
{
/// Search would take place here
if(SearchComplete != null) SearchComplete(?);
}
where "?" is the set of parameters you need to pass to invoke the delegate.
|
|
|
|
|
|
this.Invoke(**delegate required here**, args) , what you have is a method
|
|
|
|
|
Right. I should have passed the following in:
this.Invoke(new ProcessingCompleteDelegate(this.Search_ProcessingComplete));
The whole point of the Invoke... methods on the form object is not just to call a delegate, but to actually switch to the thread on which the form is running. Windows Forms are inherently single threaded due to their message loop. This is just a way to get them to run the code in question on the same thread as their message loop, instead of on the background thread. In the above example, I'm calling Invoke to get it to switch over to the UI thread and re-enter the method in that context.
|
|
|
|
|
Use an anonymous method. Here's a code snippet from an MSDN article:
public class SafeLabel : Label
{
delegate void SetString(string text);
delegate string GetString();
override public string Text
{
set
{
if(InvokeRequired)
{
SetString setTextDel = delegate(string text)
{base.Text = text;};
Invoke(setTextDel,new object[]{value});
}
else
base.Text = value;
}
get
{
if(InvokeRequired)
{
GetString getTextDel = delegate(){return base.Text;};
return (string)Invoke(getTextDel,null);
}
else
return base.Text;
}
}
}
Logifusion[^]
|
|
|
|
|
|
the only thing is that i know when invoke is and isn't required so why is this necessary? My issue is that my events do not stay registered and when i call them they are null. I'm lost in what you guys are trying to tell me.
|
|
|
|
|
Are you calling your event using if(SearchComplete != null) SearchComplete(?); or are you using Invoke? Invoke is just the wrong thing to be calling to fire your event.
Logifusion[^]
|
|
|
|
|
You guys will love this. If you simply set the CheckForIllegalCrossThreadCalls to false you can use threads just as you did in VS 2003, which is what I was doing. This was originally written in 2003 and that is why it wasn't working. Now I can manage my own threads without it complaining. What an easy fix.
|
|
|
|
|
From MSDN: When a thread other than the creating thread of a control tries to access one of that control's methods or properties, it often leads to unpredictable results. A common invalid thread activity is a call on the wrong thread that accesses the control's Handle property. Set CheckForIllegalCrossThreadCalls to true to find and diagnose this thread activity more easily.
I surely hope you don't intend to use that in production! I'm also not sure what you mean by "manage my own threads" in VS 2003. I would still get exceptions thrown indicating I was on the wrong thread even in .Net 1.1.
Logifusion[^]
|
|
|
|
|
I only have two threads in the entire application. It is very easy to keep track of what is being accessed by each thread when the number is so small. Thats all I meant. I knew this would pinch a nerve, but my 2003 application has run perfectly since I wrote it. It really is not an issue. This feature was not nearly as strict in 2003 because I ran this exact code and never received a single error.
|
|
|
|
|
Thanks for all of your help. I really appreciate it. I have another major issue however. Could you view my post on listviews. You should see it in the newer posts.
|
|
|
|
|
Did you get this one straightened out?
|
|
|
|
|
well, i reverted to a previous method. I was completely and utterly confused by this conversation.
|
|
|
|