Windows Forms

Arun.Immanuel27-Apr-07 2:16

Arun.Immanuel

27-Apr-07 2:16

Read this:

Click here

Regards,
Arun Kumar.A

Anka_Ame27-Apr-07 2:37

27-Apr-07 2:37

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?

Arun.Immanuel27-Apr-07 2:57

Arun.Immanuel

27-Apr-07 2:57

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

Anka_Ame27-Apr-07 3:04

27-Apr-07 3:04

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");
}
}
}
}

Arun.Immanuel27-Apr-07 3:27

Arun.Immanuel

27-Apr-07 3:27

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

Anka_Ame27-Apr-07 3:35

27-Apr-07 3:35

It's working to save it only like text. Thanks a lot.

Xml read in C++

Anka_Ame26-Apr-07 10:14

26-Apr-07 10:14

How can I read a Xml file from a window form? I want to know some useful function that I can use.
Thanks.

Re: Xml read in C++

pbraun27-Apr-07 8:32

pbraun

27-Apr-07 8:32

Look in your help files for "XmlDocument".

Phil

Re: Xml read in C++

sthotakura30-Apr-07 5:17

sthotakura

30-Apr-07 5:17

Samle code from MSDN

XmlDocument doc = new XmlDocument();

   //Load the the document with the last book node.
   XmlTextReader reader = new XmlTextReader("books.xml");
   reader.WhitespaceHandling = WhitespaceHandling.None;
   reader.MoveToContent();
   reader.Read();
   reader.Skip(); //Skip the first book.
   reader.Skip(); //Skip the second book.
   doc.Load(reader);

   doc.Save(Console.Out);

Cheers,
Suresh

Simple App Strategy

Brady Kelly24-Apr-07 5:07

24-Apr-07 5:07

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?

kubben25-Apr-07 2:09

kubben

25-Apr-07 2:09

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

Dave Sexton25-Apr-07 20:45

25-Apr-07 20:45

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.

Brady Kelly25-Apr-07 20:54

25-Apr-07 20:54

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.

Dave Sexton25-Apr-07 23:48

25-Apr-07 23:48

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?

Brady Kelly25-Apr-07 23:58

25-Apr-07 23:58

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!

Dave Sexton26-Apr-07 0:38

26-Apr-07 0:38

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. Smile | :)

Brady Kelly26-Apr-07 0:48

26-Apr-07 0:48

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.

Dave Sexton26-Apr-07 0:56