Using jQuery to work around a WebDev Bug

unclepetecorner

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.

2015-07-16_1628

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

2015-07-16_1631

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.

2015-07-16_1632

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

2015-07-16_1635

They you can see that the tab displays correctly

2015-07-16_1636

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>).

2015-07-16_1641

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.

2015-07-16_1700

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.

2015-07-16_1713

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

2015-07-16_1707

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.

2015-07-16_1717

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.

2015-07-16_1731

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

2015-07-16_1728

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.

2015-07-16_1732

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.

2015-07-16_1741_001

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.

5 thoughts on “Using jQuery to work around a WebDev Bug

  1. Good News! The folks at pcSoft were very quick about creating a patch for this bug. If you need the fix for this bug contact support and request the Patch for Incident 93-710

    Like

  2. Hi Pete,

    I saw your article about this bug, which by the way I am also experiencing. However, I contacted PCSoft and they sent me the patch which I followed step by step, but it didn’t corrected the problem.Did this patch worked out well on you. I was able to correct the problem in one of the tabs in my popup, but it din’t worked well on the rest of the tabs in the same popup.

    Thanks for the article.

    Best regards,

    Carlos

    Like

  3. I was able to correct the problem in one of the tabs in my popup with your code, but it din’t worked well on the rest of the tabs in the same popup.

    Like

  4. The first fix they gave me did not, but the second one did. It is tricky to get fixed as the js script file lives in several places, I suggest doing a search for the file names in the patch and make sure they are the same everywhere on your system.

    The second patch had files for ProgramsResource that the first patch did not.

    Like

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s