This week I found a bug in v20 of WebDev. To be fair it is a bug that require a number of conditions to be met before it is an issue. First you Web Page has to use some form of Anchoring by Height (I almost always have mine stretch to fill the browsers), Next you have to be using a Popup Page on that Web Page (I commonly do edit forms as popups on the same page that the browse is on, as it keeps my browse and form on the same page), and finally you have to be using a Tab Control on that Popup Page (I rarely use Tab Controls on the Web, generally its not a natural interface for the web, but for this particular site it was the right interface).

When you meet those three conditions, the tab control will be rendered as wider than you make it at design time and there really isn’t anyway around the issue, no matter how wide you make your tab it will be extended wider at runtime. This has been reported as a bug to pcSoft and hopefully we will get a fix for it, but in the meantime I need to get on with my work.

Well in our continuing jQuery and CSS series we will take a look at exactly how I tracked down the offending HTML code that was causing the tab to be rendered to wide, how I figured out what the code should look like, and finally how I used a couple of lines of jQuery in order to get the tab control to render correctly.

This article and webinar, will be a great example of why knowing HTML, CSS, and jQuery is so handy even if you are a WebDev developer, by being able to exploring the underlining HTML code, I was able to come up with a work around that lets us move forward with the site development and at the end of the day, that is all our clients care about, they don’t want to hear about who’s bug or fault it is, they just want a solution to their problem.

So lets take a look at exactly what the bug is first.  As I mentioned it requires 3 conditions. First the web page needs to have some form of height anchoring on it. In the example I have the anchoring set to center the page both by width and height. But any of the other anchoring settings that involve height would cause the same issue.

The other two conditions are that there is a Popup Page and a Tab control on that Popup Page.

When you run the page and open the Popup, you can see that the tab control has extended wider than it was at runtime. Regardless how the setting of the tab control or how wide you make it it will always expand out further than it was at design time.

However if we change the web page to not use any anchoring by height. For instance Center by Width only.

They you can see that the tab displays correctly

The first step was figuring out what was triggering the issue and a couple of hours of trial and error is what it took to figure out that the anchoring setting was causing the issue. So then the next step was to figure out specifically what in the html code was being generated incorrectly. If you have been following this series then you have probably guess the next step was to examine the HTML code via Chromes Inspect Element feature. Right clicking on the tabs and choosing Inspect element, we see that the tab control is created via an HTML table (<table>).

And that the tabs are a row (<tr>) of that table. And further that that row is split into 3 cells (<td>). The first two cells (<td>) represent the visible tabs (Pane1, and Pane2) of the tab control. The final cell is a filler to complete the width of the tab control.

If you look closely you can see the issue, the entire table is defined as 295px, the first two cells which represent the two tabs are each 52px, and the our final filler cell is defined as 295px as well. This causes that row to be 104px wider than it should be, therefore extending the entire tab control by 104px. The problem gets even worst as you add more tabs to the tab control.

This is where Chrome developer tools comes in real handy, we can test this theory in the browser without changing anything in our WebDev application.  By highlighting the line and double clicking we enter edit mode.

So 295 – 104 = 191, just encase you don’t have a calculator handy.  You might also notice that when I expanded the <td> section, there was a <div> inside it that also has the incorrect width. So if we change both of them to the correct value of 191, via the Inspect Element tool.

We will instantly see that the tab changes to be the correct width.

This is the where the real power of the Chrome developer tools starts shinning, you are able to experiment with changes to the HTML, and CSS code on the fly and see what their effect would be fore doing any coding in WebDev.

Before moving on, I need to admit I fudge a bit. If you look really closely you will see that the tab control is still a few pixels wider than it should be. Where are those extra  pixels coming from? If you click on one of the cells in the Element Inspector, and look at the computed tab, you can see there is an additional pixel used by the border.

The other two cells also have a one pixel border on the left, which is where some of our extra pixels are coming from. So that would mean we should adjust the last <td> section to 188px. But if we do it will still be one pixel wider, I confess I can’t figure out where this extra pixel is coming from but I also know how to get the number much quicker and not worry about all the math, which is really handy when you have more than a couple of tabs on your tab control.

Notice that our filler cell has a class called WDOT.

Lets right click on the web page and instead of choosing inspect element, choose view page source.

Which gives us a view of the actual html code generated by WebDev. And if we search that for WDOT, we see two instances, the second being the code we are looking for.

Notice it shows the width as 187px. So what’s going on here, why does view page source show 187px, while inspect element shows a different number 295px, before we started changing it? Well this is a good lesson in the difference between HTML and jQuery and/or JavaScript. The jQuery and JavaScript is ran on the browser, and effects the code after the fact, while view page source is the actual code downloaded from the website. So somewhere in WebDev’s JavaScript runtime library, they are changing the value after the page is downloaded. Don’t even think about asking me to dig through their JavaScript libraries and figuring out where! The good news is now I know the exact value that it needs to be 187px. And I have verified that changing the value will render by tab control correctly. So all that left is to is to figure out how to make the change via WebDev, and that can be done with a couple of lines of jQuery, once the Popup is displayed.

If you have been following this series you have seen a few advanced uses of jQuery selectors, and this is just another example. The first jQuery command, select any <td> tag, which has a class of WDOT, which selected our <td> tag in question. It then changes the css width attribute to 187px.

Our second jQuery command is very similar to the first except the selector is slightly different, this selects any <div> tag that is contained inside a <td> tag that has a class of WDOT, and again changes its width.

With those two lines of jQuery we have worked around a bug in WebDev. As important as getting around this bug was, the real lesson is the more you know about the underlining HTML, CSS and JavaScript and the use of jQuery, and how to use the tools available to work with them, the more power and flexibility you have in WebDev.

Uncle Pete’s Corner is webinar series on all things WX, to watch the watch the Uncle Pete’s corner webinar that is the companion to this article, and many other WX related webinars go to the WinDev US YouTube Channel and be sure to also join the WxLive – US Communityon Google+ to get notices about upcoming webinars. On the Google+ community you will find a active group developers discussing all things WX.

• WX