|
First, why not have the child form itself update the progress bar? Then you don't have to do all that polling.
Or if you must do polling, make sure to call Application.DoEvents() and Thread.Sleep() in your wait loop; not doing this is probably what causes the steps to "all [be] performed at once."
A little learning is a dangerous thing;
Drink deep, or taste not, the Pierian Spring.
—Alexander Pope
|
|
|
|
|
CompMan44 wrote: First, why not have the child form itself update the progress bar?
Because I don't know how to access a control (progress bar in my case) that is located on a parent form FROM a child one.
The progress bar must be in the parent form because the loop that I'm using is in the (onload event) of the child form.
So the whole idea of this progress bar is to indicate how long the child form will take to be completely load.
|
|
|
|
|
If I were you, I would investigate the BackgroundWorker class. There are many examples scattered over the net that show you how to use this with the progressbar to show progress.
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hi
You can used the Threading and Give the interval
|
|
|
|
|
Hi any developers here developing for markets other than Europe and USA,I was wondering if anybody here is developing for Arabic support (Left to Right).I was looking for a component vendor for a windows application grid that can be used display Arabic data and I expect the grid to display from right to left (mirroring).If anybody can share the experience it would be helpful.
Thanks in advance
|
|
|
|
|
I'm looking for a workaround for this .NET bug that
occurs on Win2k. The bug doesn't appear on XP.
1) Create a simple app (In C# or VB).
2) Set the form's property FormBorderStyle=None.
3) Run the app.
Notice that the taskbar only shows the app name, with no icon.
I am using Framework 1.1. Is it a known bug? any solution?
|
|
|
|
|
Please help me. I want to save some words which I enter into a textbox in an output file *.txt.
If you can help me, please do it.
|
|
|
|
|
|
if ((myStream = sfd->OpenFile()) != nullptr)
{
try
{
StreamWriter^ txtWriter;
txtWriter = gcnew System::IO::StreamWriter(filename);
txtWriter->Write(textOutput->Text);
txtWriter = nullptr;
textOutput->SelectionStart=0;
textOutput->SelectionLength=0;
txtWriter->Close();
myStream->Close();
}
}
This is something that I tried. My problem is that it doesnt save anything and it gives me a error message like "The file can not be saved because it's in use by another application".
What can I do?
|
|
|
|
|
R U trying this in the Text_change Event.
I think U R opening the file again before it is closed.
Or Can U post the entire code?
Regards,
Arun Kumar.A
|
|
|
|
|
private: System::Void saveToolStripMenuItem_Click(System::Object^ sender, System::EventArgs^ e)
{
SaveFileDialog^ sfd = gcnew SaveFileDialog();
sfd->InitialDirectory = "c:\\";
sfd->FilterIndex =2;
sfd->Filter = "TSP Files (*.tsp)|*.tsp|All files (*.*)|*.*|XML Files (*.xml)|*.xml|RTF Files (*.rtf)|*.rtf";
sfd->Title = "Save";
sfd->RestoreDirectory = true;
if (sfd->ShowDialog() == System::Windows::Forms::DialogResult::OK)
{
filename = sfd->FileName;
if ((myStream = sfd->OpenFile()) != nullptr)
{
RichTextBox^ rich = gcnew RichTextBox();
try
{
String^ strExt;
strExt = System::IO::Path::GetExtension(filename);
strExt = strExt->ToUpper();
if (strExt == ".RTF")
{
rich->SaveFile(filename);
myStream->Close();
}
else
{
StreamWriter^ txtWriter;
txtWriter = gcnew System::IO::StreamWriter(filename);
txtWriter->Write(textOutput->Text);
txtWriter = nullptr;
textOutput->SelectionStart=0;
textOutput->SelectionLength=0;
txtWriter->Close();
myStream->Close();
}
filename = sfd->FileName;
this->Text = "Editor: " + filename->ToString();
MessageBox::Show(filename->ToString() + " saved.", "File Save");
}
catch (Exception^ e)
{
MessageBox::Show(e->Message->ToString(), "File Save Error");
}
}
}
}
|
|
|
|
|
Please do the following changes and let me know if it works:
else
{
myStream->Close(); //Insert this line
StreamWriter^ txtWriter;
txtWriter = gcnew System::IO::StreamWriter(filename);
txtWriter->Write(textOutput->Text);
txtWriter = nullptr;//Remove this line.
Regards,
Arun Kumar.A
|
|
|
|
|
It's working to save it only like text. Thanks a lot.
|
|
|
|
|
How can I read a Xml file from a window form? I want to know some useful function that I can use.
Thanks.
|
|
|
|
|
Look in your help files for "XmlDocument".
Phil
|
|
|
|
|
Samle code from MSDN
XmlDocument doc = new XmlDocument();
XmlTextReader reader = new XmlTextReader("books.xml");
reader.WhitespaceHandling = WhitespaceHandling.None;
reader.MoveToContent();
reader.Read();
reader.Skip();
reader.Skip();
doc.Load(reader);
doc.Save(Console.Out);
Cheers,
Suresh
|
|
|
|
|
I'm musing over my development strategy for a very simple app for a client. They basically need a single form for edit and display of records from a single table. They also need a search on fields from that form.
Now I've never done this small an app for a client, so I have always gone the whole hog with data access layer etc., custom business objects etc. but I think for this app I would like to go with the RAD features VS provides out of the box (data binding etc.). I realise that later on we may need to expand the capabilities of the app, but I think even then the simplicity of the general business requirements will still allow this.
I'm just curious whether there are any serious caveats in taking this approach?
|
|
|
|
|
I have two comments. First if the Company has an intranet and a web server I would think seriously of making a web app. Makes it easy for anyone in the company to use the app. You might need to add some login stuff if they only want certain users to be able to access or edit the data. With a web app you don't have any deployment or update issues.
Ok second, if you still need to build the windows app if you have a data access layer that is a component or project you can easily add to the windows project solution I would just add it. I don't think there is any issue leaving out the business layer in this case since the app is just a simple editor. If you data layer isn't easy to port to other apps, then you probably have a different problem. In general it is nice to be consistant with data access across projects.
Ben
|
|
|
|
|
I reckon I'd start with the datasource, create the dataset & a mini data access layer, then work on the UI. Simple and deliverable in a few hours (sans testing/documentation).
I'd choose this approach as it's an app for a client & this is a familiar way of doing things for me hence less likely to screw up & deliver buggy software.
I know you'd like to use the RAD features on this but perhaps the "learning curve" here is better suited to a personal project for now? My opinion only.
|
|
|
|
|
Could you give me some hint as to how you would do the DAL and dataset? I would normally do entities and a data access service for reading and writing entities to the database.
Maybe you're right about the learning curve, I could always repeat the project with the RAD features as an RnD project once its delivered. I will have lots of iteration on this, so if I come up to speed on the RAD project I could swap it out.
|
|
|
|
|
It depends on the context to a fairly large degree IMO. As I understand it, it's a one table database/source with a single form. Depending on how much data needs to be worked with, how it needs to be interpreted & whether it needs to be shared across a LAN, etc. I'd decided on whether to use a database or an XML file. These and other decisions can really only be made in the context of the project's scope.
Here are my assumptions - it's a single client appliaction that needs to use a single table database, must be searchable, filtered, sorted, etc. My approach would most likely be
1. Create a test plan. Using a "test first" approach works really well for RAD. Personally I find that it tends to cut out the "extra features" bull that we as developers all too often add on & allows you to concentrate on delivering core functionality & what the client REALLY wants. Doesn't have to be a massive testing framework, just an accurate guide that you will stick to.
2. Create database & populate with sample data.
3. Create a dataset outside of the form (not as part of the single form) that'll be used for accessing/manipulating data.
4. Create a class (or set of classes depending on requirements) that will contain the core functionality of the app. Remember to still use your test plan.
5. Hook the UI up to the aforementioned class(es) using as simplistic an approach as possible. Create new controls only if absolutely necessary as this will extend your time to delivery.
6. Pass it on to the client for evaluation, & the usual story thereafter.
That help any?
|
|
|
|
|
Yes and no. Your reply confirms my initial strategy (and I'm a big TDD fan), but I was considering doing a 'no-code' type implementation, using VS wizards etc.
Forgoing that and using a properly coded DAL seems the generally preferred method, as well as being my preferred method, so I will be going with that. And it allows me to test first!
|
|
|
|
|
My mistake in interpretation, sorry.
I've done some of the "no code" approach in ASP.NET & found that to be pretty easy and efficient but it feels clumsy when applied to winforms apps (at least to me it does), which is why I tend to avoid it and go the "old faithful" route.
|
|
|
|
|
I've also found it clumsy, but I suspect it's from lack of familiarity. Anyway, I said I'd deliver a 'draft' by Friday, and didn't know Friday was a holiday, so it's a quick sprint with what's familiar later today.
|
|
|
|
|