Entries Tagged 'Work' ↓

When you write a Server Control and write it well, it pays off immensely. Today, I needed to rework our Custom Defaults screen (a screen that allows each user to define defaults for our quoting screens to use each time they write a new quote). All of the fields on the Custom Defaults screen exist in the quote (duh, why would we provide something that didn’t? ).

Since everything in the quote is a server control, it was just drag and drop the controls onto the Custom Default page and it would act 100% like it does in the quote. It could not have gone any faster, I probably only spent close to 5 minutes setting up the design and flow and 30 minutes getting the code behind functionality to work.

Thus, harness the power of Server Controls as they can be reused across numerous applications with little trouble and little programming.

Today, Aaron and I were wondering if ViewState actually works properly in .NET. For example, in .NET you have the option to disable ViewState in the web.config file, the page directive, or on each control individually. However, using any of the three methods or any combination continuously results in “__VIEWSTATE” appearing as a hidden field in the form!

The problem gets worse when you try to submit the form to another page by overriding the form’s action. This throws an “ViewState is corrupt or invalid for this page.” error. We finally got around it by hacking a JavaScript event to empty the “__VIEWSTATE” hidden field so it had nothing in it before the form actually submitted the page. But is that the only way to get rid of ViewState?

Code to cause ViewState corruption:

<script type="text/javascript">
    window.onload = function()
    {
        document.getElementById('Form1').onsubmit = function()
        {
            document.getElementById('Form1').action = '/another_project/another_page.aspx';
        }
    }
</script>

How, we got around it:

<script type="text/javascript">
    window.onload = function()
    {
        document.getElementById('Form1').onsubmit = function()
        {
            var inputFields = document.getElementsByTagName('input');
            for (var i = 0; i < inputFields.length; i++)
            {
                if (inputFields[i].name.toUpperCase() == "__VIEWSTATE")
                {
                    inputFields[i].value = ""; // Empty the ViewState hidden field to stop it from carrying on to the next page
                    break;
                }
            }

            document.getElementById('Form1').action = '/another_project/another_page.aspx';
        }
    }
</script>

Anyone else have a problem like this?

Today we had a meeting going over a few future projects and it was brought up we could integrate the new project into an existing project that had 80% the same functionality. However, there comes a lot more complication with this short of merge.

For example, what happens if two people are working in the same project on two different pieces. The first person is finished with their piece and checks it in happy as can be, while the second person finishes later and his change needs to go in ASAP, while the first person’s change can’t go in till the end of the month. Now what?

Now in a perfect world, one would state that the first person shouldn’t check in their code till it can go in, or person two would get the previous version of the first person’s code.

At work we decided to keep the projects separate and not consolidate them even though it would share 80% of the functionality for the UI. But in the end, it allows us to not step on each others toes.

So my question is, how do you handle this?