When you close a web page in Real Studio WE 2012 the div element for the page is not removed from the client browser DOM. This results in a memory leak on the client browser and presents a potential security issue. On a public computer someone could see previously displayed WE pages even if the previous user has logged out.

A quick and simple work around is to reset the Session whenever a user logs out. To do this simply call ShowURL with your web app’s address on log out. However, this does not work if the app disconnects before log out or if the user forgets to log out.

I’m releasing a class under the BSD license, SessionTD, which fixes both issues. When you close a page, SessionTD removes the page from the DOM. And it loads JavaScript which clears the DOM in the event that the app disconnects.

Click here to download the fix.

The fix was relatively simple, so I decided to make a subclass of WebLink with a similar fix for Real Studio WE users who do not have a license to Web Custom Controls. You can download the WebLinkTD class by clicking here.

To use it:

1. Add the WebLinkTD class to your project.
2. Change the Super of your WebLink controls to WebLinkTD.
3. If you assign styles in code, use WebLinkTD.StyleTD instead of WebLink.Style.

This class is released under a BSD license and is free to use. I’ve tested it on 2011r3 and 2012r2.1.

Please note that in fixing this I discovered another issue with WebLinks: once a link has been visited it will display in the visited color even on hover and click. This is not due to the WebLinkTD class. I think I know what’s going on and will report this in Feedback, and possibly try to patch this as well in a later version of WebLinkTD.

• Now the entire control div is wrapped in the link tag, not just the inner div. With this change I’ve also removed the check to see if the control is a WebButton or WebImageView. However, I have only tested the module with those two types. I imagine this could break functionality in other control types, but I leave that up to the user to test just in case it’s useful with other controls.
• This version fixes a bug which prevented the WebButton.Action event from firing on a control with a link. DoubleClick still does not fire on any browser except IE9, but I don’t consider that a bug. The other browsers are not capturing the second click because they are busy opening the link from the first click.
• This version fixes a bug which prevented WebButton.Caption and WebImageView.URL from working after a link was added.
• LinkAddTD now checks to see if a link has already been added, and if so it merely changes the existing link’s properties. This prevents multiple nested links in the event that your code accidentally calls LinkAddTD repeatedly.
• There is now a method to remove the link. If you dynamically create and delete controls at runtime, be sure to remove the link before control deletion.

This little module is released under a BSD license and is free to use. You can download the test project and module by clicking here. Enjoy!

In Real Studio WE if you want to open a URL in another tab or window, you have two options. You can use a WebLink with a target of New Window. Or you can execute some JavaScript in response to an event. Popup blockers will not block the WebLink because the user has to click it, but they will block the JavaScript even if it’s executed in response to a user click on a button or image. But what if you want to open a URL in a new window from those controls?

This question was recently asked on the forums, so I thought I would take a look and see if there was a way, and found one. Web Custom Controls 1.3 will include two functions, LinkAddTD and LinkChangeTD, which allow you to add a link to WebButton or WebImageView, and change the link later. You can control the target, which defaults to _blank and will open the URL in a new tab/window. Since this is a small bit of code and not central to nor dependent upon wcc, I’m also releasing these two functions as open source (click here to download).

There are a few catches:

1. Once you’ve added a link the Action and DoubleClick events no longer fire. MouseDown still fires.
2. Certain actions in MouseDown will prevent the link from opening. Showing a MsgBox is one. If your MouseDown code interferes with the link, try putting it in a WebTimer and starting the timer from MouseDown.
3. This works in 2011r3 and 2011r4.3, but there are no guarantees it will continue to work in the future. Real Software may change the way they organize the HTML for these controls which would break this little hack. If you organize your UI around this functionality, be prepared to change it in the future.

Otherwise this seems to work fine in the tests I’ve performed. Enjoy!

My search for an answer brought me first to this blog post. This technique is simple to implement in Realbasic. All you need to do is write a few lines of code like this:

Dim s As String = imgTest.GetData(Picture.FormatJPEG)
s = "data:image/jpeg;base64," + EncodeBase64(s)
mail.BodyHTML = "<img src=""" + s + """>"

One problem is that this technique only works with a few email clients. So I read their follow up post. This looked like something that would be easy to do as well. Unfortunately I ran into a little problem: the Realbasic EmailMessage and EmailAttachment classes do not support the attachment Content-ID header.

First I tried to get, modify, and set EmailMessage.Source, but this doesn’t work. EmailMessage parses Source, fills its properties, and generates Source again when you access it later. So the Content-ID header I was adding was lost.

Then on a hunch I tried overriding EmailMessage.Source and discovered that it is not implemented as a property but as two methods. And the solution became rather simple.

EmailMessageTD overrides the EmailMessage Source methods and allows you to customize the raw message source before sending your email. It includes another method, SetContentID, which allows you to add a Content-ID header to an attachment. If the attachment is an image you can embed the image in your BodyHTML using a line like this: <img src="cid:MyImageAttachmentId">

This class is useful for anyone who needs to modify an email message directly before sending it via SMTPSocket and avoids the tremendous hassle of having to implement full replacements for SMTPSocket and EmailMessage just to send a customized message. This was discussed on the list and it sounds like a few people have taken this rather tedious route.

I’ve tested EmailMessageTD by sending emails with embedded images using Real Studio 2011r3 and 2011r4.3. The emails I sent were correct in Mail.app and Gmail.