How to Debug Guide
In this guide you will find the basic principles on how to identify a bug and determine the optimal way to fix it.
Introduction
The first step that you want to do is to identify why is not working as expected. That is the debugging process that will be covered in this guide. Once the error has been identified, it can be solved through a generic change or with a manual change in the migrated application.
It is always advisable to look for a generic solution because the same problem that is being fixed may be present elsewhere in the application, if so, this same fix will solve that problem as well. Although sometimes for a matter of convenience is easier and faster to implement a manual change, this type of solution should only be used as the last resource, the WebMAP Silverlight team does not recommend using this type of fix.
Once that is clarified, you can proceed with an example of a basic Silverlight application that has some basic functionality, on this application you will find one Label and a Button that changes a StackPanel background color, once it is migrated to Angular it has two obvious bugs.
Source Code
Here you can download the source code that is used across the example.
Silverlight to Angular comparison
At first glance, you can see that the button that is supposed to change the color in the Angular version does not work. Another issue is that on the title the font weight is different. This is a great example since one of these bugs can be fixed with a generic change while the other one could be solved with a small manual change.
Identifying a bug
First, it must be identified why the button does not change its color, a great question will be, could it be that the button is not executing the function associated with the click?
Open up the Developer Tools on your browser, go to the Source tab, CTRL + P to open a file, in this case, the click event is inside of MainPage.ts file. Look for the function you are trying to test, in this case, it is called ClickHandler, in theory, if you set a breakpoint on the function and then click on the button, it should stop on the breakpoint. Seems like everything is working as expected.
How about testing if the value was set correctly in the component model? To review this, once again in Developer Tools, but this time on the Elements tab, this tab will show the HTML hierarchy, look for the wm-stack-panel since that is the component that should change whenever the button is clicked, once it is found, click on it to select, then on the console type the following.
Let's analyze the line above, the very first half ng.getComponent($0) is just an Angular debugging method, which returns the instance of the component, then you have .model usually a WebMAP Silverlight component will have a model, this is an object that contains all the properties and events associated with the component itself, the last part .Background is because that is the property being set on the ClickHandler. Seems like this is also fine, because every time the button is clicked, the property changes accordingly.
Two wrong attempts to solve the bug, recapping the click event is working fine, as well as the property is correctly set on the model. Could be that the property is not supported by the component? It is possible that the model supports the property but the component is not reacting to it.
Usually, a property that is supported by a component should have an input that matches the model property, take as an example this Background property, you already check that the property is set on the model but if you type.
Seems like that is the actual issue, the property is unsupported by the wm-stack-panel.
Generic Solution
This kind of solution requires changes in i-components and/or wms-framework repository. It is important to mention that this will affect all migrated code since you are changing the core library, so let's say you change the wm-button, that change will affect all the buttons present in the application. That is why you should be careful with this type of solution.
The goal is to support a new property on the wm-stack-panel component, usually, this is done by creating a setter and getter function on the component, as the following in the wm-stack-panel.component.ts file.
Let's analyze the written code, the setter function had an if statement to determine if the given value is a binding, if it is, it registers the according handlers, inside that if there is a this.modelProxy that is used as a helper object to store properties while creating the Angular component then modelProxy is copied into the actual model, Utils.createSolidBrush(value) is a helper function to transform a given hexadecimal code to a SolidColorBrush instance since that is the type of the Background property. Then there is a getter function that is using another helper function Utils.getCssColor to convert back from SolidColorBrush to a hexadecimal color that is understandable by Angular.
Once that is done, on the HTML template, you can add a simple one-way Angular binding to associate the recently added getter with a style property.
The fix must be done in the first div of the wm-stack-panel.component.html file.
It seems like the code should work, but how can you test it?
Testing solution
The migrated application has a very similar structure to any other Angular project, which means that in its package.json it has a reference to the components library.
Mobilize packages will be installed in the node_modules/@mobilize directory, here you can find two subfolders, one for the framework and one for components, in this case, changes have been made in the i-components library, it must compile and transfer its content over the node_ modules already mentioned, it is the same process for wms-framework library.
Compilation
The process of compilation for both of the WebMAP Silverlight libraries is very simple, if you want to compile i-components execute.
To compile wms-framework.
Compiled versions of both i-components and wms-framework are generated in the following folder.
Transferring
The next step would be to move the recently compiled version from the dist folder into node_modules/@mobilize on the migrated application.
Once done, the migrated project has a customized local version of components that contains the fix you just created. If you serve again, you will see that clicking the button changes the color. The first bug is solved!
Manual change
A manual change is a simpler way to solve a problem since it does not require components or framework changes and does not need a compilation process, the drawback is that this kind of change only affects the specific scenario that you are trying to solve.
Open up Developer Tools and go to Elements Tab, try adding custom font weight to the wm-label since this is the component that looks different.
Seems like that could be a possible fix. When a XAML/C# is migrated to HTML/TypeScript, it usually creates a scss file associated with the Angular component in that file you can find classes associated with the different controls present in that specific HTML template. On the image above you can see that the wm-label had a class, that comes from the MainPage.component.scss, you can add the required font-weight.
Once that is added you can save all, then serve your application again and you can see that both bugs have been solved.
Annexes
Last updated
Was this helpful?