Web Custom Controls 1.3.3 also adds a significant performance enhancement to WebListBoxTD. If you are going to add, edit, or delete multiple rows in a loop, set CacheScripts to TRUE before the loop and FALSE after. This hint lets WebListBoxTD produce more compact and faster executing JavaScript for the client.

This is a free update for all registered users.

My apologies to those of you who were waiting on these bug fixes. The changes for 2014r2.1 were a little more involved then I had anticipated.

Xojo 2014r2.1 has been released today. As some of you noticed during the beta period, r2.1 introduced a few changes which caused problems for Web Custom Controls.

I’ve been waiting until the final, public release because at least one of those changes was made late in the beta testing cycle. In this case I really didn’t want to publish an update until I knew that r2.1 was frozen.

Now that it is released I will begin final testing and publish an update that resolves those issues. My hope is to publish it tonight, but if I run into any other bugs or issues it might be a day or two.

I’m still dragging behind on my work list. Way behind. Unfortunately I’ve also found a couple of other issues with wcc on Xojo 2014r2. I really don’t want to prepare and release an update unless I’m going to fix those issues as well since testing an update is time consuming. The other issues I’ve noticed are not showstoppers and may not even be relevant to most wcc users. But that still leaves the one showstopper mentioned here.

So…for those of you who are tired of waiting and want to use wcc with Xojo 2014r2, I’m going to tell you how to fix the show stopper in this blog post.

Search your project for this line: objRequest.Header("Content-Length") =

Comment out every line with that text. You will find 7 total. You can do this by hand, but it’s faster to select all the found results and click Replace with the following text in the replace field (see attached photo): 'objRequest.Header("Content-Length") =

In a day or two I’ll upload 1.3.2 with this fix plus a few others.

The issue looks scary, i.e. the controls won’t load with a security error. But the fix is actually trivial. It’s related to a corrupted HTML header. It looks like Xojo 2014r2 wants to set the header for me and when I do it as well things go south, where in prior versions I needed to set it explicitly.

July 3 Update: I am dragging this week. I have one more task I need to finish for a client this afternoon, and this evening I can finally package/ship 1.3.2. I tried to last night but I was falling asleep.

Even though the fix is simple, I want to run all my normal tests before an update, so it’s a couple hours to prepare and upload.

I sat down to investigate it further this morning but could not reproduce it on the Mac. I then realized that I had a newer version of Chrome running, so I updated my Windows 7 virtual machine and a PC notebook I use for testing. The problem disappeared from the PC notebook, but not from my Windows 7 VM.

I can’t seem to reproduce the problem any more while testing on real PCs, but the VM still has a problem.

If anyone runs into this issue please let me know. It can probably be resolved by upgrading Chrome. But if the problem is more wide spread then I would like to investigate it further and try to determine why it does not occur when running from Real Studio. (Likely due to a CSS setting some where which was fixed or improved in Xojo thereby revealing the underlying acceleration issue.)

Simply download this Xojo module and add it to your web project. Then call FindPageTD instead of Page in code where Page is returning Nil.

FindPageTD has to search all of the controls on all of the pages for the session. A typical Xojo web app is not going to have thousands of open pages with thousands of controls on each page in a single session, so performance should not be an issue. Still, I would call FindPageTD once in a function and store the result in a variable. I wouldn’t repeatedly call it like you might call Page.

I’m releasing this under the MIT License.

Update 9/23/2013: Here’s the feedback report: feedback://showreport?report_id=29775

I believe that this only affects the jQueryFileUpload control and that the rest of the controls are working properly under r3. So if you do not use the jQueryFileUpload control your project should be fine in r3.

Original Post

I have to recommend keeping any projects which use Web Custom Controls in Xojo 2013r2 for now. Version 2013r3 has a bug in the special URL / WebRequest mechanism whereby certain input types from a POST are dropped. Some of the JavaScript controls POST data back to the server and are affected by this. jQueryFileUpload is a prime example. File data is sent via a POST and because of the bug it cannot upload files in 2013r3.

I’m not sure if there’s any work around for this. It looks like it will simply require a Xojo fix. Please note that this has nothing to do with the wcc SDK vs. the new WebSDK. It’s a problem for the controls on either.

I’m going to investigate this further and possibly file a Feedback report. However, the speed loss may be related to a legitimate bug fix, in which case it’s not likely to change. If that’s the case then I will review what changes, if any, I can make to jCanvas to restore performance.

As a result, you cannot expect the Session function to work and return a WebSession when called in a Web Custom Control event. You can, however, access the session for the event from the control. Simply call: Me.EventSession

Unfortunately this can result in other subtle bugs. For example, calling certain methods on an implicit instance page from a wcc event can result in an exception. Sometimes you can get around this by calling it via Me.EventSession (i.e Me.EventSession.MyPage.DoSomething). Sometimes you have to spin the code off into a WebTimer.

Most of the custom control and demo code makes use of Me.EventSession. However, I did inadvertently use Session in a few places. This will be fixed in the next release, 1.3.1. This should be out by July 1st.

This bug is marked as fixed so there’s a good chance the fix will appear in Xojo 2013r2. If this bug causes you any major headaches, I would recommend using Real Studio 2012r2.1 until I can upload the 1.3.1 fix and/or until Xojo 2013r2 is out.

Update 6/27 – I’m testing a fix that restores the functionality of Session in wcc events, and it seems to be working well. So it looks like 1.3.1 will fully resolve this issue. Again, this is going to be fixed in Xojo any way in release r2, but I don’t want wcc users to have to wait if possible.

Update 7/3 – bad news is that my original work around resulted in a severe performance hit. Good news is that I have another work around with no performance hit. But it’s too late in the evening (um…early in the morning) to finish testing and uploading 1.3.1. I will do this later today.