I'm relatively new to C# and Windows forms so excuse me for what may seem like an easy question.
I have a windows application which has a dialog box which when opened contains textboxes with some default values. These can be changed depending on what the user wants to use. The values in this dialog box together with the content on the main form are then used to create an XML file. The issue I have is if I go to open the dialog box again to change any values in the same session, the original values are there and not any of the new values.
How do I get it to keep the values that have been changed in that particular session?
If you want to see the user's values the next time you open the dialog box, you'll need to save those values somewhere, and then re-load them the next time the dialog is displayed (usually on Form_Load or Form_Show). And of course you'll need to save the values (probably in Form_Close?) before exiting.
Where you save those values is up to you. You can save them in some static variables in the form class if you want it to be just for that run of the program. Or you can store in a configuration file, the registry, isolated storage, etc. if you want to re-load those settings the next time the program is run.
If I'm understanding the question correctly it sounds like you need to make use of background variables and TextChanged events (although I prefer KeyDown events and my code uses that instead). For instance, let's call your textbox TextBox1. You can then make a global variable called string Temp and use it like this:
private void textBox1_KeyDown(object sender, KeyEventArgs e)
{
temp = textBox1.Text;
}
Once your dialog box is closed you can use that variable elsewhere, in your case it sounds like you want to send it to an XML.
Another option is to use the keydown event to have a temporary XML file that retains the value of your text. This is obviously more computationally expensive but it's not really that big of a deal unless this is going to be used in a processor limited environment.
The last thing I'd mention is that you may run into trouble if you're using multi-threading and passing the value of that temp value. Look into using variables on other threads than you started with for help with that.
If you want to keep the values the user entered the last time he used your dialog, you need to keep a reference to your dialog somewhere.
Also if you set some data in your dialog on the Load event it might erase the data previously entered by the user. Without seeing your code I can't tell more at this point.
Related
Let's say that we have a Form with a Button and a TextBox on it. The purpose of this app is to display a MessageBox containing the text written into the TextBox when the Button is clicked.
Is there anyway that somebody knowledgeable enough can perform malicious actions by writing code into the TextBox, or perform actions that were not a part of the app?
No, not if that's is the only thing it does.
If your textbox was to be used with building a SQL query.. that's another story.. but if all its doing is being shown in a MessageBox.. it's completely safe.
They cannot run random code either. That needs to be put through some sort of compilation process.. which doesn't happen in a string field such as the MessageBox caption/title.
I am having the exact same problem described here. Unfortunately because I don't have 50 points yet I can't comment on it so I have to create a new duplicate question.
I mean it's not "100% EXACTLY" like the other guy's problem because for me the problem exists on the Edit Form and I'm using a combination of custom forms and fields. But I am adding the custom save event handler at the field level per suggestion #2 made by the guy at this site. I should also note that when I create a new Document Library without any custom forms or Content Types and just use my custom fields straight-up, the event handler also does not fire. If however I create a new regular SharePoint list and add the custom fields then the OnSaveHandler DOES fire! I So I'm not quite sure why it doesn't work in Document Libraries but it does work in lists because I was under the impression that the beauty of custom fields was that they operate independently of everything else. Meaning, even if I was doing something wonky with my Edit Form or some other control, since I am attaching my custom method to the SPContext.Current.FormContext.OnSaveHandler in the OnInit method of my custom field then that should fire no matter what! Even when the field is being loaded for the first time I actually see the event being wired up in the debugger. In debug mode I have a breakpoint next to the "if" statement below and it hits that breakpoint which means that when the FormContext.OnSaveHandler is triggered my method should fire.
protected override void OnInit(EventArgs e)
{
base.OnInit(e);
if ((SPContext.Current.FormContext.FormMode == SPControlMode.New) || (SPContext.Current.FormContext.FormMode == SPControlMode.Edit))
SPContext.Current.FormContext.OnSaveHandler += new EventHandler(MyHandler);
}
Any thoughts? Suggestions?
Thanks!
UPDATE #1: After a little troubleshooting I was able to deduce that the EventHandler in my custom field was being fired but ONLY when used in regular lists and NOT Document Libraries! In regular SharePoint lists not only is the SPContext.Current.FormContext.OnSaveHandler being fired but the values from the custom fields are being saved as well.
As a side note, when saving the data back to my custom field that inherits from SPFieldText, the value (which is json data) displays in the list view as #VALUE!, which I think is kind of weird. I mean it's able to read the json data that's stored in the field correctly because it shows up in the Edit Form just fine. But for some reason SharePoint just displays it as #VALUE! in the list view.
So after many frustrating hours it looks like there are several issues that arise when using custom fields in a Document Library.
You can't use them in any meaningful way and expect the data to be saved when using a custom upload page. In other words, if you want to create your own custom upload page that combines the file upload input field and browse button along with your own custom fields embedded in a ListFieldIterator then the values WILL NOT BE SAVED. This is a fact! The reason is that the operation for uploading the file and creating the initial ListItem along with generating it's ID value occurs ASYNCHRONOUSLY with respect to the ListItem EventReceiver. So what does this mean exactly? It means that when you try to access the values stored in your custom field(s) in the SPItemEventProperties parameter of the ItemAdded method in the ListItem's Event Receiver all of those values will be null since the current SPContext is completely unaware of the existence of those fields and their respective values because all of the events that occur with respect to the initial document upload are executed in a different thread...asynchronously. Conversely, when the custom fields attempt to "save themselves" back to the newly uploaded document the SPField.ListItem's document ID is still set to zero because these custom fields are...you guessed it, executing in a different thread and are not "in synch" with the upload event that took place which generated the new document ID. Although I've read about a few different workarounds regarding this issue, none of them seem to work, or they are very convoluted or require you to abandon using custom fields which isn't really a workaround but more of a "throwing in the towel". One suggestion was to simply update the Elements.xml file for the EventReceiver by simply adding a "Synchronous" entry to force the event to occur synchronously instead of asynchronously. At first I thought this was too easy and too good to be true. As it turns out, I was right. :)
You can't nest a custom ListFieldIterator inside a custom control and expect your custom fields to save the data that they contain. You MUST use the ListFieldIterator directly in your form template. Period! If you try and wrap the ListFieldIterator with your custom fields in a custom control you will be very frustrated with the results.
As a side note, once the document has been uploaded and an ID has been created, you CAN enter data into your custom fields in the Edit Form and the values WILL be saved because now your code will actually be able to reference the ListItem's ID value since the ListItem will already exist in the list. Again, this is contrary to a custom upload form where the ID for the ListItem does not yet exist because you haven't actually uploaded the document yet.
I REALLY wish that Microsoft would provide some sort of update that would allow developers to get around this issue with Document Libraries and I think that it's pretty clear that they knew this was an issue when they first released SharePoint which is why the default behavior for the Document Library "New Form" is to present the user with a standalone Upload form which then redirects the user to the Edit Form so that they could avoid all of this. Of course this leaves developers who wish to allow users to upload a document and enter data on the same screen without a leg to stand on when using custom fields. Your only alternative is to use custom forms and programmatically set all of the field values and add in tons and tons of conditional logic for every single permutation of all the different fields and layout possibilities but that's a whole other animal and certainly defeats the whole reason why Microsoft created the concept of custom fields in the first place!
I have a WPF application where I'm trying to create a "diagnostics panel" that's very similar to the "Output Window" in Visual Studio 2010. It simply contains a text box where all types of output are collected and appended in the text box using the .AppendText() method.
We have a couple of customers who leave this diagnostics panel up all the time and never clear it. As a result, a very large amount of text gets displayed as new output continues to come in...
The WPF TextBox has a MaxLength property which I leave set to 0. According to the MSDN documentation, "When this property is set to 0, the maximum length of the text that can be entered in the control is limited only by available memory."
For the customers that leave this panel up, I hate to just let the text and memory grow uncontrolled... I think this may eventually cause the application to hang up...
I am curious if there's a good way to mange this... I want to keep a certain number of lines displayed in the text box and discard the oldest as new lines come in...
Any thoughts?
Thanks!
Why not use a listbox with each sentence getting its own textblock - so you can get virtualization?
http://social.msdn.microsoft.com/Forums/en/wpf/thread/98090161-0abf-4799-bbcb-852dcc0f0608
You could have a DispatcherTimer in your code behind. With this you, you can set it to Tick every 10 minutes (or whatever time period you want). And in the Tick event handler method, you can take the text in your textbox, throw away the all but the amount of text you want to save and then set the that text back to the textbox.
You could also save the text to a log text file. You'd have to figure out what to append to the text file so you won't write the same text to it multiple times. This depends on what exactly your needs are.
DispatcherTimer documenation
Like Xaisoft said, you shouldn't use a TextBox for this, probably a TextBlock instead. You might have to put that inside a ScrollViewer, I don't remember.
Here's how you handle it:
Write the log info to a text file
Write the log info to your text box (although I don't like textboxes, it should be okay.)
When writing to the text box, only display the last maybe 20 or so (play with this) lines. Everything else should "roll off"
If your users really want to save everything, no biggie, it already is saved to that file.
Upon each execution of the app, or at some appropriate interval, roll your logging to a new file.
I have a simple programme that allows input of details about a job and assign dates. Im using the project to learn c# and believe I have come a long way.
I am trying to achieve a user friendly date range input system. and because I'm using the experience to learn the programme I have decided to produce a class that draws a calender on forms when needed.
The class works very well for its initial requirements. It takes in an object (the form normally) and a point. The class then searched the database for any dates within a given range (starting with today() but can be manipulated by the form) and shows a month style block of boxes with the date and any information contained with the database.
But now I want to go the next step, and allow people to click on a specific date to select it and for a specific piece of code to be fired off. .. the only issue is! :
How do I programme a click event from the form, related to a label/drawn box that isn't there at design time...
since the labels are dynamically created at runtime I don't yet have a way to directly assign to them. I could recode the class for this, but would rather not if another way is possible.
Ideally im looking for a solution (if one exists) where when the label is clicked a method is passed the label.text. Could anyone point me in the right direction as to how to code the click event for anyone of the 50 labels that isn't created until run time?
Thanks for time to read, and even more thanks to those that reply.
Kind Regards
Paul
this.Controls["myDynamicallyCreatedControl"].Click
+= new EventHandler(MyEventHandlerMethod_Click);
private void MyEventHandlerMethod_Click(object sender, EventArgs e)
{
// Handle click event here.
}
I am programming in .NET
I have an application setting of type string.
On my form I have a textbox. I bound the text property of the textbox to my application setting. If I type something in the textbox it changes the value that is held in the Application setting but the next time I start the program it goes back to the default value. Do I need to call Properties.Settings.Default.Save(); after the text is entered for the new value to be saved? Shouldn't it do this automatically? Is there a way I can make it do it automatically?
Yes, you need to call Save explicitly. The binding changes the setting value in memory, but doesn't save the file
If you want it to be saved automatically, bind a handler to the TextChanged event and call Save() in it. It's just a double click and typing one line of code.
It is common practice to call Properties.Settings.Default.Save(); when close the application (for example, in FormClosing event).