Awesome! Just had that "trigger" moment I needed...will finish converting the rest of the jqueryui library...and, as always share Thanks Greg! Btw I converted the TinyMCE control perfectly weeks ago during beta testing but for the life of me could not understand why the click event would not fire...Was forgetting basic jquery syntax..and thanks to Derk (swort) for clearing up some questions that were mucking up my learning progression. I got so use to using the undocumented portions of the framework that it kinda became a "mental block"... (and yes, it broke the controls after the websdk )..although before websdk, that was the only option for custom advanced controls..as for the iframe issue indeed there was a conflicting grease monkey script that was conflicting with the RS framework...not sure why or how...but once disabled, the iframe issue disappeared (with ctrl+F5)... I'm sure I'll have a firm understanding after converting the 30-something controls now. That constructor is tricky at first glance... Had to make an analogy while reading through it...But cross my fingers, after a nights sleep and a day of development..I just might have it down pat! Thank you guys!

In best practices would it be advisable to let's say...create a "core" class which contains a Boolean that is set to True after a first LoadLibrary is called within a particular set of control's namespace... And check to see if the Boolean has been set to true to prevent the jquery JavaScripts from being loaded multiple times? Just curious as to "best practices" as it would seem inefficient to load the files into the webapp for each control (messy and lots of overhead)...

Noticed in the jquery date picker example that if you add 3 date pickers to a page, the jquery lib loads 3 times..

That's an oversight on our part. It's a little tricky when you think about it because you need to prevent the same session from repeatedly loading a framework, but you do want other sessions to load it. Here's what I'd suggest:

That's an oversight on our part. It's a little tricky when you think about it because you need to prevent the same session from repeatedly loading a framework, but you do want other sessions to load it. Here's what I'd suggest:

This will prevent two controls from sending the shared code to the browser. Remember this is for code that is not connected to any particular instance of your control.

Awesome! I was curious as to how to setup some sort of identifier ensuring the prevention of multiloads in a session... As an oversight...will future releases of the sdk look to see if a particular library has previously been loaded (possibly disallowing multiple calls to the same library URLs?) to prevent problems in this area? Id like to "internalize" all checks within the controls so that users utilizing the controls won't have to take sessions into consideration...basically dropping the controlset into a project and just using them like native controls...the less work the users of the controlsets have to do to use them, the better

Not sure if you've seen some of my previous collaborative works like eyeOS... But I'll be attempting to port the entire eyeOS framework (minus the implemented security protocol and ability to 'install' eyepackages (php dependent))to real studio as well...allowing users to create entire "virtual operating systems" within real studio...allowing for multiple "apps" within a single webapp... Which allows for windowed apps that appear just like desktop apps...reducing the need for a user to leave a page to access multiple apps simultaneously