Another discovery today, courtesy of Google finding Rik Robinson's Blog is String.TrimStart() and String.TrimEnd().

To trim a leading slash of a string or path use:

          myString = myString.TrimStart(newchar[]{'\\',
'/'}); 
        

To trim a trailing slash of a string or path use:

          myString = myString.TrimEnd(newchar[]{'\\',
'/'}); 
        

I had previously been using a much more long-winded approach. Cheers Rik for bringing that to my attention.

Background:

Last night I was doing a little pre-project architecture-checking work, to make sure some ideas I have for my next project will work as anticipated. One part of the web application requires a user to open a popup dialog and edit a value displayed on the main form. There are clearly many solutions to doing this, including posting back the value when submitting, and reloading the parent form when the child form closes. My prefered choice is to acomplish the task in JavaScript.

So first lets create two web pages; Parent.htm and Child.htm.

The Parent Page

In the parent page we are going to add two controls; a pre-populated readonly text box and a button to edit the contents. We will add an "onclick" handler to the button to call a JavaScript method called "editContent()", and we'll add script tags into the head section to place our code. In a real world scenario the JavaScript code would probably be placed in a seperate file.

          
            <
            html
            >
            <
            head
            >

            
              
                <
                script
                language
                ="javascript"
                type
                ="text/javascript"
                > <!--
--> </script>

              
                
                  </
                  head
                  >

                
              
            
            <
            body
            >
            <
            form
            >
            <
            input
            type
            ="text"
            name
            ="txtEditValue"
            id
            ="txtEditValue"
            value
            ="Original
content"
            readonly
            ="readonly"
            >
            <
            input
            type
            ="submit"
            name
            ="btnEdit"
            id
            ="btnEdit"
            value
            ="Edit"
            onClick
            ="editContent();"
            >
            </
            form
            >
            </
            body
            >
            </
            html
            >
          
        

In the script section we need to add some JavaScript to open the Child window. First we'll declare a global variable to hold a reference to the window in case we need it later (Possibly in a later article about Modal child forms which will use this code!).

          
            var m_childWindow = null;
        

Now we wil create the "editContent()" method which will be called from the button "onClick" handler. For the moment the "editContent()" method just calls through to the "openWindow()" method. This may seem a bit of a waste of code, but my reason for it is for program flow code reading clarrity.  The edit button (btnEdit) calls the "editContent()" method, named as it relates directly to the action the user has performed. If I had plugged btnEdit's onclick into the "openWindow()" method it would not be so logical to follow program flow. I guess using this methodalogy a better name for the "editContent()" method would have been "btnEdit_OnClick()", but hell it is just an artical on my blog, not something going into productions, so why am I tying my self up in knots over this?

The "openWindow()" method just opens a new window and assignes a reference to it top our global variable. The first parameter is teh url for the child page, the second the window name, and the third contains the properties for the window; height, width, whether to display menu bar, etc.

          
            function editContent()
{ openWindow(); } function openWindow()
{ var newWin = null;
newWin = window.open
('Child.htm', 'childWindow', 'menubar=0,resizable=0,status=1,width=350,height=250');
m_childWindow = newWin;
}
        

We now need two methods to act as accessors for the text box value; one to get and one to set.

          
            function getEditValue()
{ var editTextBox;
editTextBox = document.getElementById("txtEditValue"); return editTextBox.value;
} function setEditValue(value)
{ var editTextBox;
editTextBox = document.getElementById("txtEditValue");
editTextBox.value = value;
}
        

The Child Page

Now we'll move on to creating the child page. This will also have two controls; a TextBox and a Button. The text box will be used by the user to edit the value, and the button to submit changes back to the parent form.

          
            <
            html
            >
            <
            head
            >
            <
            script
            language
            ="javascript"
            type
            ="text/javascript"
            > <!--
--> </script></head><bodyonload="bodyOnLoad()"><form><inputtype="text"name="txtEditValue"id="txtEditValue"><inputtype="submit"name="btnSubmit"id="btnSubmit"value="Save"onClick="submitForm();"></form></body></html>
        

You will hopefully have noticed that the body onload event calls a JavaScript method called "bodyOnLoad()", so we had better create this first. The "bodyOnLoad()" method purely calls the "populateTextBox()" method via JavaScript's own "setTimeout()" method, with a quarter second delay.

          
            function bodyOnLoad()
{ setTimeout ( "populateTextBox()",
250 ); }
        

I have used the "setTimeout()" method purely becuase in tests with the Opera browser the window.opener property is not populated in time for aour call to access it in the "populateTextBox()" method. However, in Internet Explorer and Firefox, this was not the case. I presume the reason for needing this delay is to allow Opera to finish building the DOM tree. (Any one have any info on this?)

          
            function populateTextBox()
{ var editTextBox = null;
editTextBox = document.getElementById('txtEditValue'); var windowOpener = null;
windowOpener = window.opener; if(windowOpener==undefined)
{ alert('No opener'); } else { if(editTextBox
!= null)
{ editTextBox.value = windowOpener.getEditValue();
} } }
        

The "populateTextBox()" method declares two variables, one to hold a reference to the TextBox and the other a reference to the window.opener object. In this case we are assuming that the window.opener will always be our Parent.htm page and will have the "getEditValue()" method available. Obviously in a real world example this should be guarded against. So in essence once the page is loaded, the text box is populated by reading the value returned from the window.opener's "getEditValue()" method.

Editing and saving the value.

Once the value is in the text box the user is free to edit the value, and can then click the save button to call a method to send the value back to the parent form and close the child window.

          
            function submitForm()
{ var windowOpener = null;
windowOpener = window.opener; var editTextBox = null;
editTextBox = document.getElementById("txtEditValue");
windowOpener.setEditValue( editTextBox.value); window.close(); }
        

So the "submitForm()" method declares two variables to hold references to the TextBox and window opener again, and uses the window.opener's "setEditValue(value)" method to pass back the changed value to the parent form. Then the child form is closed.

Summary

So there you have it a simple JavaScript based solution for editing a value of a parent form from within a child form. My intention for my future project is to embed a RichTextEdit in the child form, and only display the finished HTML in an IFRAME on the parent form. Hopefully this will help someone who is looking to do a similar thing!

Please note through out this example error trapping and defensive coding has been ommitted for clarrity. it would also be preferable for the child page to be a modal window. I will hopefully look into a solution for that a little later.