|
MDIChildren property of the parent form would give an array of child forms. Is this what you are looking for?
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
|
This is the final code, i finally got the array in the label. Thanks
public partial class ShippingCosts : Form
{
int[,] intZip = { {33620, 5}, {33619, 10}, {33618, 12}, {33617, 13}, {33616, 14}, {33611, 18}, {33602, 22},
{33600, 25}, {33254, 26}, {33628,30}};
public ShippingCosts()
{
InitializeComponent();
}
private void btnSubmit_Click(object sender, EventArgs e)
{
int intZipCode=Int32.Parse(txtZipCode.Text);
for (int intcounter =0; intcounter <intZip.GetUpperBound(0); intcounter++)
{
if (intZipCode== intZip[intcounter,0])
{
lblResults.Text=Convert.ToString(intZip[intcounter,1]);
return;
}
else
{
lblResults.Text = "We do not deliver to this address";
}}
modified on Wednesday, November 25, 2009 8:43 PM
|
|
|
|
|
Hi,
I think it has to be Convert.ToString(intZip[intcounter,1]); to correspond to the conditional test on the line before it.
However there are better ways to do this:
1.
an array is fine when you know the number of elements in advance; otherwise you should use a list (good old ArrayList, or better yet the generic List<T> where T is some type).
2.
using a two-dimensional array like this is a little ugly. A clearer (but more expensive) way would be to create a class or struct that holds one ZIP code and one shipping quantity, then build a one-dimensional array or a generic list of such elements.
3.
and then, as you are interested in mapping one collection (ZIP codes) onto another collection (quantities), there is even better; have a look at the generic Dictionary<TKey,TValue> class. Using that, with its indexing capabilities and its Find methods, you could eliminate your for loop entirely.
4.
and finally some people will argue your data belongs in a database table, so you don't need a Dictionary, a simple SQL query would come up with the result.
PS: you have a strange return inside the if-else; I would expect both cases to be more similar, i.e. have
a return after the if-else (or none at all, if that's the end of the method).
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
your [0,1] should be [intCounter,1]
___________________________________________
.\\axxx
(That's an 'M')
|
|
|
|
|
Thank you very much guys, i knew it was something really dumb like that but i really appreciate the explanations.
|
|
|
|
|
Quick Answers giving an internal error so I posted here
1. Can any one spare the executable for July ctp of Parallel FX ? all links dead
2. Where you able to get the Parallel.for or any method of the Parallel extensions to work in VS2010 beta 2 (with .Net framework 4.0 beta 2). They say it is an added feature?
Thanks
|
|
|
|
|
Member 4277480 wrote: Can any one spare the executable for July ctp of Parallel FX ? all links dead
Reactive Extensions[^] has just been released and includes an ( unsupported ) back port for .NET 3
Member 4277480 wrote: Where you able to get the Parallel.for or any method of the Parallel extensions to work in VS2010 beta 2 (with .Net framework 4.0 beta 2). They say it is an added feature?
PFX is included in the .NET 4.0. The Parallel class is in System.Threading.Tasks and seems to work just fine
Nick
----------------------------------
Be excellent to each other 
|
|
|
|
|
Hi all,
Until some months ago, I had a tool that could log into this web: http://www.infojobs.net/empresa_login.cfm[^]
Using C# (desktop tool), i could login doing:
NameValueCollection postdata = new NameValueCollection();
postdata.Add("e_email", name);
postdata.Add("e_password", password);
postdata.Add("tipoLogin", "1");
byte[] data = webClient.UploadValues(new Uri(_loginPage), postdata);
After that, I saved the cookie and I could do other operations.
Buf since 3-4 months, this code doesn't work. I think they have changed the authentication process, but i'm not able to identify the changes. With firebug I can see that the login form is the same.
Does anybody know what have they modified?
Thanks in advanced.
PS: Sorry if this is not the place to post this thread. It's C# Code, but it's more a web problem.
|
|
|
|
|
Why don't you ask infojobs, presumably they support this process.
|
|
|
|
|
Hi,
I don't think they like this kind of access by code. With my tool, I could download many resumes in just a minute and this could stress their server.
But thanks for the answer
Regards
|
|
|
|
|
I want simple way to give feedback to the user while the main thread is busy.
In the main thread I want something like
<br />
ProgressBox prog = new ProgressBox();<br />
prog.Show();<br />
for ( int i=0 ; ; i++ ) {<br />
...<br />
prog.NumProcessed = i; <br />
}<br />
prog.Close();<br />
The problem is that the ProgressBox freezes after a couple of seconds and updates only once after the loop is finished.
Ok, it has something to do with Threading. However, I have tried to find a solution, but all seems to come down to performing the work(the for loop here) in another thread.
But this is not what I want. I want the work to be performed in the main thread for simplicity if the main thread has to wait anyway!
The ProgressBox can run in separate thread, I could not care less. But I need a generic solution for feedback to the user instead of a "looks like a crash".
I might just be too stupid, but anyone already stumbled across a solution to this.
regards Rolf
modified 2-Aug-18 21:02pm.
|
|
|
|
|
Hi,
You MUST do the long operation in a separate thread (a Thread object, a ThreadPool thread, a BackgroundWorker, whatever) and NOT on the main thread as that needs to be available at all times to keep the GUI alive (and update all forms/controls, including progress bars).
If the long operation needs access to the GUI you may want to read this[^], unless a simple BackgroundWorker suffices.
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
modified on Wednesday, November 25, 2009 5:00 PM
|
|
|
|
|
Luc
If I take your canonical pattern and shove it into a static utilities class (possibly extending it by checking the typeof control) I presume this would act as a global thread safe control updater (only called when using a second thread naturally).
|
|
|
|
|
Yes you could do that; I never used it that way, most often I don't even pass the Control, I tend to create one or a few dedicated methods for each control (as there aren't that many) within the Form class, but there probably isn't a good reason for doing so, except for providing a more functional name to the method.
Note some actions may need more parameters, say setting the n-th item in a listbox.
And then there is the performance issue when you need to update a lot, it is wise to pass all data and cross the thread barrier only once.
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
I have 2 common operations that I want to perform from a thread, update a textbox or label (typically with the name of a completed process) or increment a progress bar so testing to the progress bar and an else would meet 90% of my needs.
Where I need to update a listview, which I often need to, I would use a specific delegated method.
|
|
|
|
|
If I understand you correctly, I would create a couple of global methods then, one for SetText (taking a Control, as all Controls have a Text property; and a string), one for SetProgress (taking a ProgressBar, not a Control, and a number), etc.
That's a bit more code (statically), however it does not perform any unnecessary type checking (with as and is).
BTW: especially for progress bars, make sure you don't update progress at a ridiculous precision; if you're not careful each iteration would cause a thread switch and possibly just confirm the previous version (assuming you are using a small range of values, say percentages). So it may be worthwhile to "cache" the latest value and short-circuit when there isn't a real change.
(I should add this to my article)
FWIW: this holds true as well when using BackgroundWorker.ReportProgress(), however I haven't seen this kind of warnings in MSDN yet.
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Thinking about it I had already come to the 2 method solution and thinking more I will probably create a generic listview updater as well. I always do the same thing when processing a list of stored procs, uncheck the item, add the record count and time to sub items.
Luc Pattyn wrote: don't update progress at a ridiculous precision
Been there, I regularly process 100k+ result sets, you very quickly learn to lighten the load when using a progress bar . I think it should be sooooo obvious the warning would be a little redundant.
|
|
|
|
|
Mycroft Holmes wrote: the warning would be a little redundant
Now I disagree. Too often I've seen code (not mine!) that would run say 10 times faster by commenting out the progress bar, sometimes making it so fast a progress bar doesn't make much sense any more. Remember, with the Invoke in place, a thread switch could easily dominate the bulk of the loop code.
Seems some people lack a feeling for normal and abnormal speed.
[EDIT]The article has been updated.[/EDIT]
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Totally agree with you. You don't have to update the progress bar unnecessarily. 
BTW, I used to use BeginInvoke than Invoke when I need to update the controls. This executes as an asynchronous call and won't block the worker thread until progress bar is updated.
Best wishes,
Navaneeth
|
|
|
|
|
yes, you have told me that before; I did not react on it then, other than start thinking about it. So I did, and I decided not to change my ways.
Of course I do agree you can use BeginInvoke, and it has the advantage of not blocking the worker.
However it does not really fit my "canonical form", where a single method can be called from the GUI thread as well as any other thread. If I were to use BeginInvoke there, it would be a synchronous method when called from the GUI thread, and asynchronous when called from another thread, which would probably be very confusing.
The same point, in other words, is: I prefer asynchronous operations to be obvious from their name, so "Begin" or "Async" should be part of the method name, which then wouldn't be possible in my canonical form.
Another, minor, issue might be: I do not like the idea of a lot of GUI work piling up somewhere, as this (1) would consume memory nobody is aware of, and (2) will consume a lot of CPU cycles even after the worker has finished.
Of course, if the net result would be fewer thread switches (I should perform an experiment), then it would have its merits.
And finally, I just added to the article a remark about avoiding frequent progress bar updates; having them synchronous should make it easier for the programmer to notice something is going wrong in that area.
If and when I do some experiments on this, I'll let you know the results.
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Luc Pattyn wrote: Of course, if the net result would be fewer thread switches (I should perform an experiment), then it would have its merits.
I don't think BeginInvoke has this advantage over Invoke as both are doing the same API call internally. All it does extra is to run the method in a separate thread to get asynchronous nature.
Luc Pattyn wrote: If and when I do some experiments on this, I'll let you know the results.
Thanks. I will be very much interested to hear from you.
Best wishes,
Navaneeth
|
|
|
|
|
Luc is correct, the right way to do this is to do the operation in another thread and make that thread report back the progress to the GUI thread so it can update progress bars or whatever. This is exactly what the BackgroundWorker component was designed for.
Dave
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)
Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
The easiest way is to write Application.DoEvents() inside the for loop. This will allow the application to process its message queue and update the Progress bar, but the downside is that your loop can become slower by upto 10 times (or even more).
Using a BackgroundWorker is the most appropriate choice for background activities. It runs your code in a separate thread which allows your main thread to process other messages and update the GUI.
|
|
|
|
|
calling Application.DoEvents() is dangerous; for one it risks a StackOverflowException. I do not recommend it unless I am sure the programmer knows the internals of the Windows messaging system (in which case he probably does not need any advice and wouldn't have asked the question at all).
Luc Pattyn [Forum Guidelines] [My Articles]
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
