Problem Solution to working code that stops working
-
I am really fed up with .NET and C# and really wish I stayed with Java or anything else that isn't so contrary and idiotic :wtf: . I recently, had a problem with an online report written with Developer Express Reporting tools within a .NET/C# intranet web-site. The report being a summary of the entire application utilized sub-reports to sub-reports to sub-reports, when one of the bottom-level sub-reports failed to be populated when it was working fine and there were no updates to any of the associated code. I spent days trying to figure out why it stopped working and to find a fix. In the end a friend familiar with this type of problem had me rename the method that was no longer firing then create a new method with exact same signature as the original method that wasn't working. When tested, the new empty method would fire just fine where the old method had quit working no matter what was done with it. Next I merely copied the original code from the old method to the new one, ran it and the report was fixed :wtf: . My next step before publishing was to delete the original method. I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here. The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them??? The other problem I have with this is at one sub-report level the method signature created is different than at the lower level. In this case the method that would not run was called:
private void xrInvAllegations_BeforePrint(object sender, PrintEventArgs e)
{ . . .However, the equivalent method signature at the higher (Investigations sub-report control's level uses the following:
private void xrSacwisInvestigations_BeforePrint(object sender, System.Drawing.Printing.PrintEventArgs e)
{ . . .I do NOT understand why the same method call would use two different sets of parameter signatures, which overly confuses the issue, and why one would just decide, I am not going to work anymore until you copy me into a new block with the exaxt same method signature! I can't begin to express how totally frustrating this is and I definately hate to publish a fix on such a flimsy excuse for what was wrong. Can anyone explain a better reason why rewriting the exact same code should be used as fix for method that stops firing? us
The funny thing that C# has a very prominent similarity to Java... It is not a C# or VS problem. DevEx had declared the delegate in different way (one time with namespace and at the other without)... (You can look inside there assembly and see this - just don't tell me) It IS frustrating, but you can make it better - provide clear code!!!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
-
I am really fed up with .NET and C# and really wish I stayed with Java or anything else that isn't so contrary and idiotic :wtf: . I recently, had a problem with an online report written with Developer Express Reporting tools within a .NET/C# intranet web-site. The report being a summary of the entire application utilized sub-reports to sub-reports to sub-reports, when one of the bottom-level sub-reports failed to be populated when it was working fine and there were no updates to any of the associated code. I spent days trying to figure out why it stopped working and to find a fix. In the end a friend familiar with this type of problem had me rename the method that was no longer firing then create a new method with exact same signature as the original method that wasn't working. When tested, the new empty method would fire just fine where the old method had quit working no matter what was done with it. Next I merely copied the original code from the old method to the new one, ran it and the report was fixed :wtf: . My next step before publishing was to delete the original method. I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here. The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them??? The other problem I have with this is at one sub-report level the method signature created is different than at the lower level. In this case the method that would not run was called:
private void xrInvAllegations_BeforePrint(object sender, PrintEventArgs e)
{ . . .However, the equivalent method signature at the higher (Investigations sub-report control's level uses the following:
private void xrSacwisInvestigations_BeforePrint(object sender, System.Drawing.Printing.PrintEventArgs e)
{ . . .I do NOT understand why the same method call would use two different sets of parameter signatures, which overly confuses the issue, and why one would just decide, I am not going to work anymore until you copy me into a new block with the exaxt same method signature! I can't begin to express how totally frustrating this is and I definately hate to publish a fix on such a flimsy excuse for what was wrong. Can anyone explain a better reason why rewriting the exact same code should be used as fix for method that stops firing? us
RBKpro wrote:
The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them???
Nope. Visual Studio doesn't execute your code. So, no. That's not the problem and, frankly, i've never heard of such a problem with Visual Studio or the .NET CLR. Chances are REALLY good that it's a problem with DevEx. Either the DevEx isn't raising the event or the event handler wasn't wired up properly. BTW, those two method headers are NOT the same. The first one leaves some room for ambiguity if the
PrintEventArgstype is defined in multiple namespaces, which is not unheard of.A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
I am really fed up with .NET and C# and really wish I stayed with Java or anything else that isn't so contrary and idiotic :wtf: . I recently, had a problem with an online report written with Developer Express Reporting tools within a .NET/C# intranet web-site. The report being a summary of the entire application utilized sub-reports to sub-reports to sub-reports, when one of the bottom-level sub-reports failed to be populated when it was working fine and there were no updates to any of the associated code. I spent days trying to figure out why it stopped working and to find a fix. In the end a friend familiar with this type of problem had me rename the method that was no longer firing then create a new method with exact same signature as the original method that wasn't working. When tested, the new empty method would fire just fine where the old method had quit working no matter what was done with it. Next I merely copied the original code from the old method to the new one, ran it and the report was fixed :wtf: . My next step before publishing was to delete the original method. I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here. The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them??? The other problem I have with this is at one sub-report level the method signature created is different than at the lower level. In this case the method that would not run was called:
private void xrInvAllegations_BeforePrint(object sender, PrintEventArgs e)
{ . . .However, the equivalent method signature at the higher (Investigations sub-report control's level uses the following:
private void xrSacwisInvestigations_BeforePrint(object sender, System.Drawing.Printing.PrintEventArgs e)
{ . . .I do NOT understand why the same method call would use two different sets of parameter signatures, which overly confuses the issue, and why one would just decide, I am not going to work anymore until you copy me into a new block with the exaxt same method signature! I can't begin to express how totally frustrating this is and I definately hate to publish a fix on such a flimsy excuse for what was wrong. Can anyone explain a better reason why rewriting the exact same code should be used as fix for method that stops firing? us
"
Quote:
I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here.
The above statement does not compile: Stackoverflow error.
"What Turing gave us for the first time (and without Turing you just couldn't do any of this) is he gave us a way of thinking about and taking seriously and thinking in a disciplined way about phenomena that have, as I like to say, trillions of moving parts. Until the late 20th century, nobody knew how to take seriously a machine with a trillion moving parts. It's just mind-boggling." Daniel C. Dennett
-
I am really fed up with .NET and C# and really wish I stayed with Java or anything else that isn't so contrary and idiotic :wtf: . I recently, had a problem with an online report written with Developer Express Reporting tools within a .NET/C# intranet web-site. The report being a summary of the entire application utilized sub-reports to sub-reports to sub-reports, when one of the bottom-level sub-reports failed to be populated when it was working fine and there were no updates to any of the associated code. I spent days trying to figure out why it stopped working and to find a fix. In the end a friend familiar with this type of problem had me rename the method that was no longer firing then create a new method with exact same signature as the original method that wasn't working. When tested, the new empty method would fire just fine where the old method had quit working no matter what was done with it. Next I merely copied the original code from the old method to the new one, ran it and the report was fixed :wtf: . My next step before publishing was to delete the original method. I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here. The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them??? The other problem I have with this is at one sub-report level the method signature created is different than at the lower level. In this case the method that would not run was called:
private void xrInvAllegations_BeforePrint(object sender, PrintEventArgs e)
{ . . .However, the equivalent method signature at the higher (Investigations sub-report control's level uses the following:
private void xrSacwisInvestigations_BeforePrint(object sender, System.Drawing.Printing.PrintEventArgs e)
{ . . .I do NOT understand why the same method call would use two different sets of parameter signatures, which overly confuses the issue, and why one would just decide, I am not going to work anymore until you copy me into a new block with the exaxt same method signature! I can't begin to express how totally frustrating this is and I definately hate to publish a fix on such a flimsy excuse for what was wrong. Can anyone explain a better reason why rewriting the exact same code should be used as fix for method that stops firing? us
RBKpro wrote:
I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here.
Have you ever contacted DevExpress? Used their forums? While I understand your frustration I would have thought a calm, well documented, correspondence would elicit the best response. Any software provider will look at well presented issues and try to help - but having a rant isn't the best way to go about solving your issue.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
-
RBKpro wrote:
I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here.
Have you ever contacted DevExpress? Used their forums? While I understand your frustration I would have thought a calm, well documented, correspondence would elicit the best response. Any software provider will look at well presented issues and try to help - but having a rant isn't the best way to go about solving your issue.
MVVM # - I did it My Way ___________________________________________ Man, you're a god. - walterhevedeich 26/05/2011 .\\axxx (That's an 'M')
_Maxxx_ wrote:
but having a rant isn't the best way to go about solving your issue.
But it is dramatically more satisfying. And you go and bring logic and common sense to a rant tch tch.
Never underestimate the power of human stupidity RAH
-
I am really fed up with .NET and C# and really wish I stayed with Java or anything else that isn't so contrary and idiotic :wtf: . I recently, had a problem with an online report written with Developer Express Reporting tools within a .NET/C# intranet web-site. The report being a summary of the entire application utilized sub-reports to sub-reports to sub-reports, when one of the bottom-level sub-reports failed to be populated when it was working fine and there were no updates to any of the associated code. I spent days trying to figure out why it stopped working and to find a fix. In the end a friend familiar with this type of problem had me rename the method that was no longer firing then create a new method with exact same signature as the original method that wasn't working. When tested, the new empty method would fire just fine where the old method had quit working no matter what was done with it. Next I merely copied the original code from the old method to the new one, ran it and the report was fixed :wtf: . My next step before publishing was to delete the original method. I'd complain to DevEx, but I am sure they will insist it is a Visual Studio (2012 Ultimate) problem and Microsoft will say it is a DevEx problem, so I am posting my complaint here. The only kind of explanation I have is VS sometimes has a problem with recognizing method signatures as being valid and therefore will not execute them??? The other problem I have with this is at one sub-report level the method signature created is different than at the lower level. In this case the method that would not run was called:
private void xrInvAllegations_BeforePrint(object sender, PrintEventArgs e)
{ . . .However, the equivalent method signature at the higher (Investigations sub-report control's level uses the following:
private void xrSacwisInvestigations_BeforePrint(object sender, System.Drawing.Printing.PrintEventArgs e)
{ . . .I do NOT understand why the same method call would use two different sets of parameter signatures, which overly confuses the issue, and why one would just decide, I am not going to work anymore until you copy me into a new block with the exaxt same method signature! I can't begin to express how totally frustrating this is and I definately hate to publish a fix on such a flimsy excuse for what was wrong. Can anyone explain a better reason why rewriting the exact same code should be used as fix for method that stops firing? us
First thing. Those signatures are totally identical. So I don't know what you're complaining about public void foo(Color x); is identical to public void foo(System.Drawing.Color x) If you are importing the System.Drawing namespace that is. I think java has namespaces too. Second thing. When it wasn't firing, did you check that you are actually subscribing/wiring up xrInvAllegations_BeforePrint method to an event? I strongly suspect what you probably did was accidentally not subscribe to the event. Then you probably used the visual studio IDE to create a 'new' event via using the forms designer. The forms designer probably subscribed to the event for you, and hence xrInvAllegations_BeforePrint now gets called correctly. Which fixed your problem (In a stupid round about way) On the non firing version. I'd go check you actually have code somewhere that looks like someClass.SomeEvent += xrInvAllegations_BeforePrint; If you don't, it's pretty obvious why it's not getting fired :P Functions and methods don't magically get called unless you tell something you want them to be called.
-
First thing. Those signatures are totally identical. So I don't know what you're complaining about public void foo(Color x); is identical to public void foo(System.Drawing.Color x) If you are importing the System.Drawing namespace that is. I think java has namespaces too. Second thing. When it wasn't firing, did you check that you are actually subscribing/wiring up xrInvAllegations_BeforePrint method to an event? I strongly suspect what you probably did was accidentally not subscribe to the event. Then you probably used the visual studio IDE to create a 'new' event via using the forms designer. The forms designer probably subscribed to the event for you, and hence xrInvAllegations_BeforePrint now gets called correctly. Which fixed your problem (In a stupid round about way) On the non firing version. I'd go check you actually have code somewhere that looks like someClass.SomeEvent += xrInvAllegations_BeforePrint; If you don't, it's pretty obvious why it's not getting fired :P Functions and methods don't magically get called unless you tell something you want them to be called.
Matty22 wrote:
When it wasn't firing
Matty22 wrote:
why it's not getting fired
Employees get fired. Events get raised.
The difficult we do right away... ...the impossible takes slightly longer.
-
First thing. Those signatures are totally identical. So I don't know what you're complaining about public void foo(Color x); is identical to public void foo(System.Drawing.Color x) If you are importing the System.Drawing namespace that is. I think java has namespaces too. Second thing. When it wasn't firing, did you check that you are actually subscribing/wiring up xrInvAllegations_BeforePrint method to an event? I strongly suspect what you probably did was accidentally not subscribe to the event. Then you probably used the visual studio IDE to create a 'new' event via using the forms designer. The forms designer probably subscribed to the event for you, and hence xrInvAllegations_BeforePrint now gets called correctly. Which fixed your problem (In a stupid round about way) On the non firing version. I'd go check you actually have code somewhere that looks like someClass.SomeEvent += xrInvAllegations_BeforePrint; If you don't, it's pretty obvious why it's not getting fired :P Functions and methods don't magically get called unless you tell something you want them to be called.
Matty, Sorry for not replying sooner. Your explanation is the kind of explanation I was looking for, as it explains why it wouldn't fire and reason for needing to rewrite (and re-subscribe) it identical to the first version. The one thing is doesn't explain that I find the most confusing is that to have had it coded, subscribed to, and working, with no other changes, is why it suddenly became "unsubscribed" and stop working necessitating the steps that had to be taken. Is there something the user could have done or moreover some possible data constraint violated that would "Unsubscribe" the event? If so this is what needs to be identified so that something can be done so it doesn't happen again. I had suspected the two different signatures may have been the same, but then DevEx should use ony one and not confuse the issue by randomly choosing one or the other that only makes one waste hours looking at them as a cause for the mysterious "unsubscription".
-
Matty, Sorry for not replying sooner. Your explanation is the kind of explanation I was looking for, as it explains why it wouldn't fire and reason for needing to rewrite (and re-subscribe) it identical to the first version. The one thing is doesn't explain that I find the most confusing is that to have had it coded, subscribed to, and working, with no other changes, is why it suddenly became "unsubscribed" and stop working necessitating the steps that had to be taken. Is there something the user could have done or moreover some possible data constraint violated that would "Unsubscribe" the event? If so this is what needs to be identified so that something can be done so it doesn't happen again. I had suspected the two different signatures may have been the same, but then DevEx should use ony one and not confuse the issue by randomly choosing one or the other that only makes one waste hours looking at them as a cause for the mysterious "unsubscription".
Reason it may have not been subscribed: 1. You were using the visual studio forms designer; moved the control, cut and paste, played with the properties or otherwise changed the control in the designer and forgot to subscribe your method to the relevant event in the UI designer and the emitted *.designer.cs was missing the subscription you wanted 2. You were subscribing by hand without knowing what you are doing and subscribed to the event in a bad place in the applications life cycle. Eg, after the event had been fired. Solution to 1 and 2 as with all things is to know what you are doing. The most important thing to do is obviously identify the the place in your code where you subscribe to the event. If you can't locate where you subscribe to the event; then it's not surprising methods don't get called when you expect them to and you need to read more about how events work and .NET in general.. If you do know where you are subscribing and you've checked using the debugger that it gets called at an appropriate time in the applications life cycle then it's DevEx's problem as they're not triggering the event reliably, which is probably unlikely.
-
Matty22 wrote:
When it wasn't firing
Matty22 wrote:
why it's not getting fired
Employees get fired. Events get raised.
The difficult we do right away... ...the impossible takes slightly longer.
Microsoft uses all of fired, triggered and raised interchangeably Example from the "Event" article on the MSDN "An event often has no custom data; the fact that the event was fired provides all the information that event handlers require. In this case, the event can pass an EventArgs object to its handlers. The EventArgs class has only a single member, Empty, that is not inherited from System.Object. It can be used to instantiate a new EventArgs class." "An event delegate is used to define the signature of the event. A particular event delegate typically corresponds to a particular event data class. By convention, events in the .NET Framework have the signature EventName(sender, e), where sender is an Object that provides a reference to the class or structure that fired the event" I guess you better get MS on the phone and tell them all about the sand in your knickers
