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 . 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 . 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:
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
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.
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.
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
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".
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.
Last Visit: 31-Dec-99 18:00 Last Update: 7-Mar-14 22:17