What I learned today

Problem: In one of the classic application there was a requirement to support Unicode for graphic displays characters. Analysis: The libraries of the application were not supporting Unicode characters and the graphic displays  in this library were in Visual Basic. Custom applications uses this library extensively and the solution must not affect the existing users. So, changing of library was not feasible solution. An out of box solution was necessary. Solution : Without changing the library, if some thing can be done in the runtime then that would suit all the needs. So in the run time based on the font, a corresponding Unicode font was identified and replaced in the controls before the displays were presented. By this way there was a slight increase in the call up time but it was ok for achieving the desired functionality. For not affecting existing customers a flag was introduced to run old or new code.

Problem : While uploading a large set of OPC properties, the uploader would fail randomly Analysis:  Initially the uploader would fail for some properties. On checking these properties via an OPC client everything seemed to be ok. So the easiest fix was to increase the time out of the uploader. This fixed the issue at that point. But the fix didn't last long, again some of the properties would fail to subscribe. This time after debugging it was observed that some properties received had bad values. This properties were ignored by the uploader. Hence one more collection was added to keep a tab on those properties and re-subscribe after rest of the properties are uploaded. The fix worked for most of the cases and for many days without any issues. Then one fine day the issue reappeared. On further debugging, it was observed that this time the failure was a combination of above two symptoms. Few properties having bad data on re-subscription also failed. T...

Problem:  Displays of an application gets black if it was left unattended for few hours.  Analysis: Mouse hovering could some times get the display back. Or moving to another display would solve the issue.  Initially I thought it to be a graphic driver issue, updated the driver software, Still the problem persisted. Then disabled hard ware acceleration but the problem was still present.  Then I thought it may be some performance issue in the terminal server. But the problem was repeatable even if a single client was opened also.  Guessed that the issue might be with bitmaps caching of remote desktop protocol (RDP). Hence, disabled the "Persistent bitmap caching" for the terminal server client and it worked.  Solution:  Disabling the "Persistent bitmap caching" for the remote clients

I have been doing software design, development and resolving complex issue for quite some time now. The journey has been a continuous learning experience each passing day. The motive of this blog is to share summary of each day henceforth with the hope that this gained  knowledge  can hep me or others in due coarse of time. 

Problem : When few trends were opened in an application, no performance issue were noticed. But if ten or more trends would be opened each trend having around seven traces in average, the application would hang. Analysis : On analysis it was noticed that the CPU load would be high leading to the application hang. On digging further, the trend drawing event would consume most of the CPU. Hence the drawing of the traces was reviewed. It was noticed that once the traces reach till the end of X axis, its logic had  some flaw where for each trend traces were being drawn again instead of removing or hiding the old points and joining the end points incrementally. The above fix would solve half of the problem. Then it was further optimized by suspending the paint events of the trends that were not in view for some time. The drawing event will resume once the trend display is viewed again. Solution : The performance of the trend was improved by implementing incremental joining ...