|
Hi im building a program to scrape links from a webpage, To prevent the document complete even tfiring multiple times ive set it to the function below.
public void BrowserCallback(object sender, EventArgs e)
{
WebBrowser Thread = (WebBrowser)ThreadViewer.Controls["Thread"];
while (Thread.ReadyState.ToString() != "Complete")
{
Application.DoEvents();
}
LinkScraper CurrentForm = new LinkScraper();
MethodInfo methodInfo = typeof(LinkScraper).GetMethod(NextFunction);
methodInfo.Invoke(CurrentForm, null);
}
My problem is that referencing the current form with
LinkScraper CurrentForm = new LinkScraper();
wipes out all the created controls from the previous method, Is there any way to use methodInfo.Invoke without having the same issue ?
|
|
|
|
|
First, you should be posting this in the asp.net forum.
Second, you could store the data in server variables (there's a word for these, but I can't for the life of me remember it) and retrieve them in the new instance of the form..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
If this is a WinForms app (I can't tell from your post), then:
1. you are in the right forum;
2. if using WebBrowser, you should rely on the WebBrowser.DocumentCompleted event (and watch the URL that goes with it to decide whether it is the last one)
3. if you don't need to see the web page, you would be better of using HttpRequest and HttpResponse, which don't use any Control, and can work synchronously. This is how I do most web scraping.
Some coding comments:
1. a WebBrowser and a Thread are two different things, so calling a WebBrowser Thread is confusing everyone, you in the first place.
2. having a loop of DoEvents() is a horrible hack.
3. you should not use strings for something that is not inherently a string, so please replace Thread.ReadyState.ToString() != "Complete" by Thread.ReadyState!=WebBrowserReadyState.Complete
tyjnfghnfgsdf wrote: To prevent the document complete even tfiring multiple times ive set it to the function below.
I don't understand you here. Is this the method that will handle the DocumentCompleted event? having it wait for completion doesn't achieve much; the multiple events will fire anyway, so they will get queued in the message queue and confuse you with some delay.
 Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
hi,
i have a main form. it has list view of items that when clicked will open up another form without closing the main form.
i did a inactivity timeout where user will be require to login again. if that happen, how do i close all current open form??
|
|
|
|
|
| You need to keep form objects that are open in a collection. When relogin requires, loop through this list and dispose everything. Best wishes,
Navaneeth
|
|
|
|
|
N a v a n e e t h wrote: loop through this list and dispose closeeverything.
Don't use dispose on a form that is currently displayed - unpredictable things may occur!If Barbie is so popular, why do you have to buy her friends?
Eagles may soar, but weasels don't get sucked into jet engines.
If at first you don't succeed, destroy all evidence that you tried.
|
|
|
|
|
When I say dispose everything, I didn't meant to call Dispose() method. BTW, how it can cause unpredictable things?  Best wishes,
Navaneeth
|
|
|
|
|
| If the form has a background thread working, it could be using resources that you have disposed. If Barbie is so popular, why do you have to buy her friends?
Eagles may soar, but weasels don't get sucked into jet engines.
If at first you don't succeed, destroy all evidence that you tried.
|
|
|
|
|
| Application.OpenForms will return a Forms[] for all open forms. You can for loop through it closing the ones you no longer need (with Form.Close(), obviously). Do not try to foreach loop through, as the Close() may remove it from the array. If Barbie is so popular, why do you have to buy her friends?
Eagles may soar, but weasels don't get sucked into jet engines.
If at first you don't succeed, destroy all evidence that you tried.
|
|
|
|
|
im implementing windows mobile using compact framework so there isn't application.openforms.
is there something else similar?
|
|
|
|
|
| Not unless you create it yourself - keep a copy of the form object when you do the create, chain into the FormClosing event and remove it when it closes. You can then manually Close() each open instance. If Barbie is so popular, why do you have to buy her friends?
Eagles may soar, but weasels don't get sucked into jet engines.
If at first you don't succeed, destroy all evidence that you tried.
|
|
|
|
|
hi OriginalGriff,
what you mean is to create a class which act as a application hub that store all created form instances??
im sorry but wat do u mean by chain into the formClosing event?
|
|
|
|
|
Store them as part of your main form, as either an array of Form objects, or as individual YourForm references. At the moment, you do something like
YourForm yf = new YourForm();
yf.Show(); when the use clicks one of your list view entries - just move the "YourForm yf" outside the method (and give it a better name).
You then change it to
yf = new YourForm();
yf.FormClosing += new EventHandler(YourFormClosing);
yf.Show(); and add
private void YourFormClosing(object sender, EventArgs e)
{
yf = null;
}to remove it when it closes.
You can then check
if (yf != null)
{
yf.Close();
}If Barbie is so popular, why do you have to buy her friends?
Eagles may soar, but weasels don't get sucked into jet engines.
If at first you don't succeed, destroy all evidence that you tried.
|
|
|
|
|
hmm okay i will go try it out. tks again Original Griff
|
|
|
|
|
You could simply call Form.Hide() instead of closing the forms outright..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
|
Let me first start with what I am trying to accomplish and what I have.
I created a computer management console for active directory. You launch, it gets all computer objects from AD. When you click the computer object, some panels become visible and thre are 3 listbviews. One for Installed Applications, One for Services, and one for Hard drive information. All of that information is retrieved by WMI.
So the way I have it is when you click a computer object, it attempts to contact the computer using seperate threads for each thing (applications, services, hd info).
I have something like this:
Thread m_workerThread1;
Thread m_workerThread2;
Thread m_workerThread3;
Semaphore resourceLock;
When you click comp:
if (m_workerThread1 != null && m_workerThread1.IsAlive)
m_workerThread1.Abort();
if (m_workerThread2 != null && m_workerThread2.IsAlive)
m_workerThread2.Abort();
if (m_workerThread3 != null && m_workerThread3.IsAlive)
m_workerThread3.Abort();
lstServices.BeginUpdate();
lstServices.Items.Clear();
m_workerThread1 = new Thread(new ParameterizedThreadStart(GetRunningServices));
m_workerThread1.IsBackground = true;
m_workerThread1.Start(comp.DnsHostName);
lstApplications.BeginUpdate();
lstApplications.Items.Clear();
m_workerThread2 = new Thread(new ParameterizedThreadStart(GetInstalledApps));
m_workerThread2.IsBackground = true;
m_workerThread2.Start(comp.DnsHostName);
lstDiskDrives.BeginUpdate();
lstDiskDrives.Items.Clear();
m_workerThread3 = new Thread(new ParameterizedThreadStart(GetCompInfo));
m_workerThread3.IsBackground = true;
m_workerThread3.Start(comp.DnsHostName);
And under each method (you see I am calling three different ones) I am using the resourceLock.WaitOne(); and under a try catch finally (in the finally) I am releasing it.
You might be wondering why I call abort. This is because I really couldn't think of a better way to abort the current operation if the user clicks another computer. Having it wait until its done before letting the user choose another computer really isn't an option (because WMI can take a while sometimes).
My problem is if you close the form while these threads are running. Right now I forgot to include anything for it and it causes teh app to crash.
Is there a good way to abort these and then close? Like without displaying a message for the user to wait and try again until it aborts? What is the "best practice" for handling something like this? Or did I just mess the whole system up the way I did it?
|
|
|
|
|
Looks like you are not clear about what a Semaphore does. I haven't got why you are using it here.
Jacob Dixon wrote: You might be wondering why I call abort. This is because I really couldn't think of a better way to abort the current operation if the user clicks another computer. Having it wait until its done before letting the user choose another computer really isn't an option (because WMI can take a while sometimes).
Whole point of using threads is to allow users to do things in parallel. This means that, user should be able to browse multiple computer details and each should open in it's on windows. So user don't have to wait until an operation finishes and you don't have to abort threads forcefully. Also, I don't see any reason to create new threads each time. Queuing the tasks into ThreadPool should be good enough. ThreadPool threads are background threads.
Jacob Dixon wrote: My problem is if you close the form while these threads are running. Right now I forgot to include anything for it and it causes teh app to crash.
A background thread should get aborted automatically when the main thread exits. Are you sure the main thread exits correctly? I guess the WaitOne call on Semaphore is blocking main thread and screwing up something.
Jacob Dixon wrote: What is the "best practice" for handling something like this?
IMO, allow users to view details of multiple computers. Clicking each computer will queue a job to the worker thread and open a new window (or tab?) to show the details. So user can view computer details while other requests gets processed in the background. Avoid calling Abort(), avoid creating your own threads instead use a ThreadPool. Also make sure your main thread is not blocked.
 Best wishes,
Navaneeth
|
|
|
|
|
I created three threads and didn't want more than 3 running at one time. Thats why I used the semaphore. I haven't used a Threadpool before (new to threading as you might can tell lol). Let me read some on it and see what I can do with it.
Duh yeah opening in new windows would be more practical. Don't ask me why I didn't do that. I had a treeview on the left with the computers and on the right the listvies that displayed the info on the cmoputers. Im going to go with the new window suggestion lol.
|
|
|
|
|
I would try to use async WMI calls.
ManagementObjectSearcher query = new ManagementObjectSearcher(managementScope, new ObjectQuery(szSelectStatement));
ManagementOperationObserver observer = new ManagementOperationObserver();
observer.CompletedEventHandler += ;
ManagementObjectCollection queryCollection = query.Get(observer);
Now you should wait for 2 events in your threads. The first event signals that your
query is completed. And the second event should signal that the thread should cancel
the query (observer.Cancel()).
Now you can sync your threads without having the need of abort them.Greetings
Covean
|
|
|
|
|
I have never had any luck with ManagementOperationObserver. I have posted on multiple forums (incluiding Microsoft) of why it fails.
If I'm correct you can use that for installing applications. Using it allows you to view detailed information about the install running (like what it is doing). I've only been able to get it to work on local machine and not when doing remote instaleld with WMI.
|
|
|
|
|
|
I never worked with remote WMI so I never ran in this problem.
So back to the topic.
I think in your case you can abort your threads.
But I think it would be a better solution, to tell the thread (you want to abort) that it should exit immediately after it finished its query and leave it alone/let it run till its exits (maybe you should add a kind of observer to abort threads, that didn't finish in a determined timeout).
So you couldn't use your semaphore any more (because of the possibility, that more than 3 threads are running) but it would be better to let the thread make a clean exit.
Why I think this is a better solution?
WMI calls are made through some unmanaged (not sure) COM interfaces.
Now if you abort your thread, there maybe will be some resources that would be still locked and never
gets freed till the application exits.
On the other hand you could also try to do some clean up in your thread if it gets aborted.
Something like this:
public void ThreadFunc(object obj)
{
try
{
DoSomeOperation();
}
catch(ThreadAbortException ex)
{
DoAbortCleanupStuff();
}
finally
{
}
}
I hope that helps.Greetings
Covean
|
|
|
|
|
I've been asked to write a script that runs on certain files across a server. These files are always stored within the same location within each top level folder e.g
Server\folder1\mydoc\file
Server\folder2\mydoc\file
Server\folder3\mydoc\file
Server\folder4\mydoc\file
So I have a script that runs on 'file'
I need this script or another program to monitor 'Server' finding all 'files' in that location to process and also to find 'file' whenever a new folder eg 'folder5' is created.
Is this even possible? I have no idea how to proceed or what to start reading up on to work out how to be able to do this.
Many Thanks
|
|
|
|
|
You could write a windows service that monitors the folders (with a FileSystemWatcher object), and fires off a processing thread whenever a new file is copied to one of the folders..45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
