A **script widget** is a collection of (internal) controls and a behavior script which, from the point of view of the outside world, function as a single object - lessons 
An instance of a script widget always appears as a single element when on a card, regardless of how many controls it contains, is always selected as a single control and does not allow internal controls to be directly referenced from outside.
Script widgets are manipulated in script using the widget chunk, can define properties (using setProp and getProp handlers), and can send messages to and receive messages from other controls.
Importantly, unlike custom property handlers defined on normal controls, attempting to set and get properties of script widgets will always call the handlers – regardless of whether messages are locked.
# Test your widget At this point you should be able to create an instance of your widget and see what it looks like. Since script widgets are 'loaded' when the implementation stack is in memory, you don't have to use the extension builder at this point - simply create a stack and execute create widget as "com.livecode.widget.editablelabel" in the message box.
# parentPropertyChanged Some standard control or object properties cannot be overridden as widget properties. In this case the widget implementation is notified of a property change by the parentPropertyChanged message.
This can be used to ensure that property changes made by the user can be handled appropriately. For example, the textAlign property is not inherited from the parent, so if it is set on the widget, code is needed to ensure that the field controls within the script widget change alignment accordingly.
# propertyMetadata In order for a script widget to become a bona-fide integrated object, it needs to have a certain level of metadata. Firstly it needs some top-level metadata - a title, type, author and version. This is also where the widget's description can be added, which is displayed in LiveCode documentation when the widget is installed. The widget also needs property metadata to function correctly in the IDE. This is specified using a special custom property handler, propertyMetadata, which is used at compile time to generate information about how the widget properties should be displayed in the property inspector, and also what properties the widget has by default when dragged out from the Tools palette.
# Documentation In-line documentation for a definition is extracted from a `/* ... */` comment block immediately before the start of the definition. Always add a top-level documentation block at the start of the LCB file describing your widget, library or module. In addition, add in-line documentation to all of the following:
syntax definitions property definitions public handler definitions in libraries and modules public variable definitions in modules It is particularly important to add documentation to all syntax and to any public handlers that aren't primarily accessed using syntax. Additionally, add documentation for all messages that are posted by a widget. The documentation for each message must be placed in the top-level documentation block for the widget. For example:
/* The navigation bar widget is intended for use in mobile apps for switching between cards, although there are many other possible uses. ... Name: hiliteChanged Type: message Syntax: on hiliteChanged Summary: Sent when a navigation item is selected ... */ widget com.livecode.widget.navbar -- .. end widget
Please refer to the Extending LiveCode guide for full details of the syntax of in-line documentation comments, including examples.
# Variable naming Use consistent variable names to make your code easier to understand. It may not seem important now, but when you have forgotten how it works 6 months later it will help to make it readable. It also makes it easier to exchange you code with other members of the LiveCode community, when you need to get help with something. Character Example Usage g gVar Global variables t tVar Handler-local variables s sVar Script-local variables p pVar Parameters k kVar Constants c cVar Custom properties Variable scope As a general rule of thumb, use a variable with just enough scope and no more for the task at hand. In other words, if a handler local variable is all you need for a calculation, don't use a script local. If a script local would do, don't use a global. This makes it less likely that you will introduce unexpected errors into your code by using the same variable name for different purposes. A handler local variable only has meaning within that handler so you can safely use the same variable name in other handlers.