Inheriting Code

[KallDrexx]

So as a software developer in QA I'm looked to for developing and maintaining tools (mostly because real developer's time is booked for actual product development, so it's easier to bill it to QA). One of the developers wrote a tool a while ago that went through our TFS server and extract information from work items that had code checked in between two labels. He got tired of dealing with the tool and convinced management to get it passed onto me. I got it and 2 days later I started getting bug reports from developers. No problem, so I start going through the code, and what a clusterfuck.

First of all, I start going through the core backend classes. All 25 methods of the class are private static, with one public static method. This isn't a utility class that's used all throughout, it's a core (and complex) operation class that is called in only one part of the application.

The whole backend is intertwined, so in order for me to step through the application to debug this issue I have to run through the whole 1.5 hour process, because I literally have to rewrite his code in order to be able to do something as simple as "run the code for only one specific TFS changeset", and instead I have to tell it to run through ALL labels.

When going through the code I found several gems, such as:

                    if (((ChangeFrom.ChangeType.ToString().Contains(ChangeType.Branch.ToString()))
                        && !(ChangeFrom.ChangeType.ToString().Contains(ChangeType.Merge.ToString())))
                        && !PathDirectionUp)

For reference, ChangeFrom is an instance of the TFS Change class, and Change.ChangeType is a value from the ChangeType enum. So he could simplify the previous code with

if (changeFrom.ChangeType == ChangeType.Branch && !(changeFrom.ChangeType == ChangeType.Merge) && !PathDirectionUp)

I then went through some other string handling code that I think might be a potential spot where the original bug I"m trying to figure out comes from. In his main form class he has the following method defined:

        private void SetDdl(string ddl)
        {
            txtSqlScript.Text =  StringHandler.GetTextOutOfHtml(ddl);
        }

So I look at where this SetDdl method is being called, and find this code:

                if (txtSqlScript.InvokeRequired)
                {
                    SetDdlCallback ddlCallback = new SetDdlCallback(SetDdl);
                    this.Invoke(ddlCallback, new object[] { ddl });
                }

This is in the EXACT SAME CLASS as the SetDdl method definition (and no, no methods are static amazingly). For some reason just calling the method straight up would be too easy.

The code is littered with wtfs, including a lot of if statements without brackets that have nested ifs and else/else ifs inside of them. Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.

[heterodox]

@KallDrexx said:

if (changeFrom.ChangeType == ChangeType.Branch && !(changeFrom.ChangeType == ChangeType.Merge) && !PathDirectionUp)

 

Am I too tired for cognitive function this morning or is that second check not even required? If changeFrom.ChangeType == ChangeType.Branch, then changeFrom.ChangeType can't == ChangeType.Merge. And why would you use !(==) instead of != anyway?

@KallDrexx said:

                if (txtSqlScript.InvokeRequired)
                {
                    SetDdlCallback ddlCallback = new SetDdlCallback(SetDdl);
                    this.Invoke(ddlCallback, new object[ { ddl });
                } 

 

That code is absolutely correct if your application is multi-threaded (i.e., that code could be called by a thread that is not the UI thread). Otherwise, kill it with fire.

[boomzilla]

@heterodox said:

@KallDrexx said:

if (changeFrom.ChangeType == ChangeType.Branch && !(changeFrom.ChangeType == ChangeType.Merge) && !PathDirectionUp)

Am I too tired for cognitive function this morning or is that second check not even required? If changeFrom.ChangeType == ChangeType.Branch, then changeFrom.ChangeType can't == ChangeType.Merge. And why would you use !(==) instead of != anyway?

I suspect that if you looked at the history, one of those &&s was an ||. Probably looking for a branch or a merge, and then the requirement changed (or the code was incorrect to begin with), and that was how the coder changed it because it seemed simpler or more obviously logically correct to him. I've done that sort of thing when pondering a complex condition, though I usually catch it after the initial change and simplify it.

[KallDrexx]

I was just doing a quick writeup of how he's doing enums incorrectly, but you are correct that I can further get rid of the 2nd check (which I probably would have realized once I modified the real code).

You have a good point about the second issue quoted about multi-threaded, although it is being done in a non-background thread when there will be only one thread ever active performing that action (and it will only be performed once the thread is about to finish and never called again), but I concede on this one.

[frits]

Having a QA dev maintain internal tools sounds like a productivity nightmare to me.

[KallDrexx]

@frits said:

Having a QA dev maintain internal tools sounds like a productivity nightmare to me.

Why? It's what I was hired to do, to create and maintain automation and internal tools to streamline our QA processes. It's just expanded from just QA tools to process management and misc internal tools.

[DaveK1]

@heterodox said:

@KallDrexx said:

if (changeFrom.ChangeType == ChangeType.Branch && !(changeFrom.ChangeType == ChangeType.Merge) && !PathDirectionUp)

Am I too tired for cognitive function this morning or is that second check not even required? If changeFrom.ChangeType == ChangeType.Branch, then changeFrom.ChangeType can't == ChangeType.Merge. And why would you use !(==) instead of != anyway?

It would be worth verifying that there aren't any members of the enum whose names contain both 'Branch' and 'Merge' as substrings, just to be on the safe side that the original version of the code didn't perhaps actually mean what it said. 

@heterodox said:

@KallDrexx said:

                if (txtSqlScript.InvokeRequired)
                {
                    SetDdlCallback ddlCallback = new SetDdlCallback(SetDdl);
                    this.Invoke(ddlCallback, new object[ { ddl });
                } 

 

That code is absolutely correct if your application is multi-threaded (i.e., that code could be called by a thread that is not the UI thread). Otherwise, kill it with fire.

Genuine question here: why is it correct, when the code being callbacked just does some string processing and doesn't touch the UI?  I don't understand the need for it.

[DaveK1]

@KallDrexx said:

The whole backend is intertwined, so in order for me to step through the application to debug this issue I have to run through the whole 1.5 hour process, because I literally have to rewrite his code in order to be able to do something as simple as "run the code for only one specific TFS changeset", and instead I have to tell it to run through ALL labels.

@KallDrexx said:

Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.

Can you seriously really not find a way to work smarter not harder using conditional or counting breakpoints?

[KallDrexx]

@DaveK said:

@KallDrexx said:

The whole backend is intertwined, so in order for me to step through the application to debug this issue I have to run through the whole 1.5 hour process, because I literally have to rewrite his code in order to be able to do something as simple as "run the code for only one specific TFS changeset", and instead I have to tell it to run through ALL labels.

@KallDrexx said:

Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.

Can you seriously really not find a way to work smarter not harder using conditional or counting breakpoints?

I'm not an idiot, I've been programming for quite a while. I started with conditional breakpoints, but it's not as easy as it sounds. The problem is that the final string output of the application is being mangled in some way that is ruining the Sql Scripts it's supposed to be displaying. I've already set up MSTest unit tests on the actual string manipulation functions and verified that they are not the cause of the mangling. The sql script concatenation is handled at the very end of the process, after it runs through and performs all the queries on the TFS database for every single changed file in every single changeset in the list between the two TFS labels (yes it's inefficient, yes I need to go through and redo all of his code to make it not take an hour and a half, but that's no trivial matter in the way he architected this code).

When I call the code to on form load to display the sql script in the text box (providing the final output) everything displays properly, but it only doesn't display properly when it runs through the whole processes. I think I have tracked it down to a retarded Infragistics rich text control that seems to arbitrarily mess the text up, and I'm testing it now, but I can't find a way to repeatably cause the third party control to mess the text up without running through the whole process.

I replaced the Infragistics text box with a normal text box and I think that'll fix it but I"m waiting for the whole process to run through so I can verify it. P.s. He used his personal Infragistics license for this tool, and was telling me that legally I should change out Infragisistics controls with either Telerik (which we have a license) or just winforms to keep it legal. *sigh*

[frits]

@KallDrexx said:

@frits said:

Having a QA dev maintain internal tools sounds like a productivity nightmare to me.

Why? It's what I was hired to do, to create and maintain automation and internal tools to streamline our QA processes. It's just expanded from just QA tools to process management and misc internal tools.

Because internal tools are usually not written with maintenance and quality ideals in mind.  Maintaining these things usually requires someone to just do what needs to be done, while resisting the urge to refactor, which may open up cans of multiple cans of worms.  Due to their pedantic nature, QA folks are usually not a good fit for this.

[boomzilla]

@KallDrexx said:

@DaveK said:

@KallDrexx said:

Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.

Can you seriously really not find a way to work smarter not harder using conditional or counting breakpoints?

When I call the code to on form load to display the sql script in the text box (providing the final output) everything displays properly, but it only doesn't display properly when it runs through the whole processes. I think I have tracked it down to a retarded Infragistics rich text control that seems to arbitrarily mess the text up, and I'm testing it now, but I can't find a way to repeatably cause the third party control to mess the text up without running through the whole process.

I replaced the Infragistics text box with a normal text box and I think that'll fix it but I"m waiting for the whole process to run through so I can verify it. P.s. He used his personal Infragistics license for this tool, and was telling me that legally I should change out Infragisistics controls with either Telerik (which we have a license) or just winforms to keep it legal. *sigh*

This is the sort of situation where it seems like logging could more easily narrow down the point where it happens. That way you can let it run, and just come back at the end and see where the change occurred. At least, that's where I might have started. If the real problem is the 3rd party control like you think, one run through should have told you that.

The personal license thing is just icing on the WTF cake.

[Guest]

@DaveK said:

Genuine question here: why is it correct, when the code being callbacked just does some string processing and doesn't touch the UI?  I don't understand the need for it.

 

It is touching the UI - it is setting the text of the textSqlScript control.

[TheCPUWizard]

@KallDrexx said:

I was just doing a quick writeup of how he's doing enums incorrectly, but you are correct that I can further get rid of the 2nd check (which I probably would have realized once I modified the real code).

You have a good point about the second issue quoted about multi-threaded, although it is being done in a non-background thread when there will be only one thread ever active performing that action (and it will only be performed once the thread is about to finish and never called again), but I concede on this one.

 

If there is Ever the possibility of a UI becoming multi-threaded [can you ever guarantee what will happen to the code in the next 5 years? I cant'. So the safe presumption is that at some point the code may become used in a MT environment] then having the InvokeRequired conditional code is the way it should be coded from day 1.  If I had $10 for each time a piece of UI code eventually became problematic because of a threading issue (which did not exist at the time the code was originally written and tested) I would have already retired.

[KallDrexx]

@frits said:

@KallDrexx said:

@frits said:

Having a QA dev maintain internal tools sounds like a productivity nightmare to me.

Why? It's what I was hired to do, to create and maintain automation and internal tools to streamline our QA processes. It's just expanded from just QA tools to process management and misc internal tools.

Because internal tools are usually not written with maintenance and quality ideals in mind.  Maintaining these things usually requires someone to just do what needs to be done, while resisting the urge to refactor, which may open up cans of multiple cans of worms.  Due to their pedantic nature, QA folks are usually not a good fit for this.

I guess it depends on how much oversight you have. I'm given pretty good freedom here so I make sure to write all my tools in a maintainable way, because I know that I am going to have to fix any issues with it and respond to changes in processes. I have done some pretty big refactoring when required, but then again my boss trusts me that when I say that I need to fix some issues with my tool that I'm not just wasting time and that I know what I'm doing / talking about. But then again that probably also stems from being in QA and not product development

This is the sort of situation where it seems like logging could more easily narrow down the point where it happens. That way you can let it run, and just come back at the end and see where the change occurred. At least, that's where I might have started. If the real problem is the 3rd party control like you think, one run through should have told you that.

Yeah probably. Long story short I was thrown off because it didn't happen before some changes I made in the HTML stripping method (which fixed another issue), so I was more focused on the stripping code was working properly. However, I finally figured out it was the third party code by changing the method to

        private void SetDdl(string ddl)
        {
            PreFormattedLastGeneratedDDL = ddl;
            PostFormattedLastGeneratedDDL = StringHandler.GetTextOutOfHtml(ddl);
            txtSqlScript.Text = PostFormattedLastGeneratedDDL;
        }

because I saw that the pre and post formatted DDLs were correct, but after the method run txtSqlScript.Text was mangled. However, when I took the same exact pre formatted DDL in and on page load called SetDdl() with it, the text box was formatted correctly (thus only formatted incorrectly when run from the other thread after the whole process), which made things confusing. I should also mention that I wasn't focused 100% on this for 3 days straight, but I was working on other stuff in that time.

If there is *Ever* the possibility of a UI becoming multi-threaded [can you ever guarantee what will happen to the code in the next 5 years? I cant'. So the safe presumption is that at some point the code may become used in a MT environment] then having the InvokeRequired conditional code is the way it should be coded from day 1. If I had $10 for each time a piece of UI code eventually became problematic because of a threading issue (which did not exist at the time the code was originally written and tested) I would have already retired.

Thanks, I honestly didn't know that. Though usually in this case I use a .Net backgroundworker thread, so my UI updates do occur on the GUI thread properly anyway.

[DaveK1]

@ShatteredArm said:

@DaveK said:

Genuine question here: why is it correct, when the code being callbacked just does some string processing and doesn't touch the UI?  I don't understand the need for it.

 

It is touching the UI - it is setting the text of the textSqlScript control.

Thanks for clearing that up, I don't know C# enough to infer that something's a control without seeing its declaration.

 

[frits]

@KallDrexx said:

I'm given pretty good freedom here so I make sure to write all my tools in a maintainable way, because I know that I am going to have to fix any issues with it and respond to changes in processes.

I wasn't talking about maintaining your own programs.  Anyone can do that.  I was referring to maintenence of tools others have written and abandoned (like you described in the original post).

[boomzilla]

@KallDrexx said:

        private void SetDdl(string ddl)

{

PreFormattedLastGeneratedDDL = ddl;

PostFormattedLastGeneratedDDL = StringHandler.GetTextOutOfHtml(ddl);

txtSqlScript.Text = PostFormattedLastGeneratedDDL;

}

because I saw that the pre and post formatted DDLs were correct, but after the method run txtSqlScript.Text was mangled. However, when I took the same exact pre formatted DDL in and on page load called SetDdl() with it, the text box was formatted correctly (thus only formatted incorrectly when run from the other thread after the whole process), which made things confusing. I should also mention that I wasn't focused 100% on this for 3 days straight, but I was working on other stuff in that time.

In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?

[KallDrexx]

I wasn't talking about maintaining your own programs. Anyone can do that. I was referring to maintenence of tools others have written and abandoned (like you described in the original post).

Oh right, I read that wrong.

In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?

Exactly. So when I ran txtSqlScript.Text = PostFormattedText; and then looked at the txtSqlScript.Text value, that value was the mangled text, even though PostFormattedText string was still the correctly formatted string.

[C_Octothorpe]

@KallDrexx said:

I wasn't talking about maintaining your own programs. Anyone can do that. I was referring to maintenence of tools others have written and abandoned (like you described in the original post).

Oh right, I read that wrong.

In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?

Exactly. So when I ran txtSqlScript.Text = PostFormattedText; and then looked at the txtSqlScript.Text value, that value was the mangled text, even though PostFormattedText string was still the correctly formatted string.

Is the txtSqlScript a custom control (sorry if you already answered this question).  If so, why not just run through the code of the txtSqlScript.Text setter, or if you don't have access to the source, just use reflector on it and see what's going on inside.

[KallDrexx]

@C-Octothorpe said:

@KallDrexx said:

I wasn't talking about maintaining your own programs. Anyone can do that. I was referring to maintenence of tools others have written and abandoned (like you described in the original post).

Oh right, I read that wrong.

In reference to the bolded text...I'm not sure I follow you. I'm guessing (haven't touched C# in at least 5 years) that this is a property setter? Was the text getting mangled at that point? And then when you fetched it from the control, it was bad?

Exactly. So when I ran txtSqlScript.Text = PostFormattedText; and then looked at the txtSqlScript.Text value, that value was the mangled text, even though PostFormattedText string was still the correctly formatted string.

Is the txtSqlScript a custom control (sorry if you already answered this question).  If so, why not just run through the code of the txtSqlScript.Text setter, or if you don't have access to the source, just use reflector on it and see what's going on inside.

The control is a proprietary rich text box by Infragistics. The fact that it's manipulating the string it's supposed to be displaying (instead of using the string it's given and rendering it correctly) is ridiculous and unacceptable in my opinion. I should be able to retrieve the pre-rendered string from the text box. Yes, I could use reflector to see what it's setter is doing to modify the string, but what's the point? Furthermore, the only purpose of the text box on the GUI is to display the sql script, that in 100% of all use cases the user is going to copy all of the text into sql server management studio. There's no purpose to rich text formatting this at all.

[DaveK1]

@KallDrexx said:

@DaveK said:

@KallDrexx said:

The whole backend is intertwined, so in order for me to step through the application to debug this issue I have to run through the whole 1.5 hour process, because I literally have to rewrite his code in order to be able to do something as simple as "run the code for only one specific TFS changeset", and instead I have to tell it to run through ALL labels.

@KallDrexx said:

Meanwhile I've spent a good bit of the last 3 days trying to debug this issue, since I can only get the issue to happen when I run through the full hour and a half process.

Can you seriously really not find a way to work smarter not harder using conditional or counting breakpoints?

I'm not an idiot, I've been programming for quite a while. I started with conditional breakpoints, but it's not as easy as it sounds. The problem is that the final string output of the application is being mangled in some way that is ruining the Sql Scripts it's supposed to be displaying. I've already set up MSTest unit tests on the actual string manipulation functions and verified that they are not the cause of the mangling. The sql script concatenation is handled at the very end of the process, after it runs through and performs all the queries on the TFS database for every single changed file in every single changeset in the list between the two TFS labels (yes it's inefficient, yes I need to go through and redo all of his code to make it not take an hour and a half, but that's no trivial matter in the way he architected this code).

Sorry, I misread your first sentence above as implying that you had had to step through the whole thing, but on second reading I realise it doesn't actually say that. 

@KallDrexx said:

When I call the code to on form load to display the sql script in the text box (providing the final output) everything displays properly, but it only doesn't display properly when it runs through the whole processes. I think I have tracked it down to a retarded Infragistics rich text control that seems to arbitrarily mess the text up, and I'm testing it now, but I can't find a way to repeatably cause the third party control to mess the text up without running through the whole process.

I replaced the Infragistics text box with a normal text box and I think that'll fix it but I"m waiting for the whole process to run through so I can verify it. P.s. He used his personal Infragistics license for this tool, and was telling me that legally I should change out Infragisistics controls with either Telerik (which we have a license) or just winforms to keep it legal. *sigh*

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

[KallDrexx]

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

OMG, how do you do this? That would be amazing to know.

[DaveK1]

@KallDrexx said:

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

OMG, how do you do this? That would be amazing to know.

Well, on VMware there's a menu option (in the management interface) or button you click (on the virtual console window toolbar) that snapshots the entire state of the virtual machine, and another one that rolls back your VM to the last taken snapshot.  I don't know but would expect other VMs to have similar facilities.  In the last resort, you could choose whatever option to sleep/suspend the VM that the software offers, and then take backups of the VM state files to recopy back later, but I'd be surprised if that was actually necessary.

[KallDrexx]

@DaveK said:

@KallDrexx said:

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

OMG, how do you do this? That would be amazing to know.

Well, on VMware there's a menu option (in the management interface) or button you click (on the virtual console window toolbar) that snapshots the entire state of the virtual machine, and another one that rolls back your VM to the last taken snapshot.  I don't know but would expect other VMs to have similar facilities.  In the last resort, you could choose whatever option to sleep/suspend the VM that the software offers, and then take backups of the VM state files to recopy back later, but I'd be surprised if that was actually necessary.

Oh, for a minute I thought you were referring to the .Net CLR. I would give an arm and a leg if Visual Studio had the capability to do that.

[DaveK1]

@KallDrexx said:

@DaveK said:

@KallDrexx said:

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

OMG, how do you do this? That would be amazing to know.

Well, on VMware there's a menu option (in the management interface) or button you click (on the virtual console window toolbar) that snapshots the entire state of the virtual machine, and another one that rolls back your VM to the last taken snapshot.  I don't know but would expect other VMs to have similar facilities.  In the last resort, you could choose whatever option to sleep/suspend the VM that the software offers, and then take backups of the VM state files to recopy back later, but I'd be surprised if that was actually necessary.

Oh, for a minute I thought you were referring to the .Net CLR.

Ah, but then I would have said "... run the app through once, in a VM in a VM with a debugger attached ..."! 

@KallDrexx said:

I would give an arm and a leg if Visual Studio had the capability to do that.

 

Yeah, wrapping up the whole debugging environment in a VM and resetting it to snapshot isn't nearly as convenient as if the debugger could just reset the target app state, because of course when you rewind the VM you lose all the associated changes you may have made in the debugger itself, like breakpoints and watches and so on.  But in the case of an hour-and-a-half run-up to the actual bug site being reduced to a 'click the restore button and wait twenty seconds' operation, I can put up with having to keep an open notepad running on the machine hosting the VM and copy-and-paste a few debugger commands back in each time I restart!

[bjolling]

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

I also run my development environments in different virtual machines on VirtualBox and never considered using it like that. Thanks DaveK, another trick in my toolbox

[Jaime]

@KallDrexx said:

@DaveK said:

@KallDrexx said:

@DaveK said:

Ugh.  Having to debug problems in third-party code with no sources is definitely not fun.

How about you run through the app once, in a VM with a debugger attached, then snapshot the VM so you can repeatedly resume at the point just after the hour-and-a-half and just before the bug occurs?

[Edit: well, I guess that would be a useful suggestion if you hadn't already identified the bug.]

OMG, how do you do this? That would be amazing to know.

Well, on VMware there's a menu option (in the management interface) or button you click (on the virtual console window toolbar) that snapshots the entire state of the virtual machine, and another one that rolls back your VM to the last taken snapshot.  I don't know but would expect other VMs to have similar facilities.  In the last resort, you could choose whatever option to sleep/suspend the VM that the software offers, and then take backups of the VM state files to recopy back later, but I'd be surprised if that was actually necessary.

Oh, for a minute I thought you were referring to the .Net CLR. I would give an arm and a leg if Visual Studio had the capability to do that.

Would you settle for being able to see the past? 2010 has IntelliTrace.

[KallDrexx]

Would you settle for being able to see the past? 2010 has IntelliTrace.

That's pretty awesome, I need to keep that reference handy.

So in dealing with the WTFs I posted in here (mainly the bug fix) I pushed out a new build that had everything fixed. Mind you, the bugs I were fixing were bugs the original coder made. Well it seems the Development team doesn't trust that I can program and I know what I am doing, so they had someone do some before and after tests to verify the script it outputs is correct (even though I already did that in fixing this bug). I can guarantee they NEVER doubted the original programmer that wrote the bugs originally. I've also since found other WTFs in there that I don't really feel like writing a whole post on.

In other news, I just got a full time developer job at a good company and gave my current place 2 weeks notice, so someone else can deal with this piece of crap.

[Lorne Kates]

@KallDrexx said:

In other news, I just got a full time developer job at a good company and gave my current place 2 weeks notice, so someone else can deal with this piece of crap.

 

Glad to hear the QA slog paid off.

BTW, a bit late to the party, but anytime I hear "rich text editor" and "something sometimes stops working", in my experience it's almost always something messed up with the input text. A mismatched quote, or a tag that wasn't closed. Whever broke-ass renderer they use leaks unclosed tags out into the rest of the page.

[PJH]

@Lorne Kates said:

A mismatched quote, or a tag that wasn't closed. Whever broke-ass renderer they
use leaks unclosed tags out into the rest of the page.

Oh - bit like a belated welcome to Community Server then?