Documentation guide
General information
Documentation Center
Frequently Asked Questions
Release notes
How does it work
Pricing
Get a trial version license
Public QA Tests
QA Tests and Examples
For the first steps
Installation
Quick Start
Troubleshooting
Advanced Users
Users guide
Users guide Advanced
DHTML and JavaScript integration
What's new in V2.0
Release notes
ICDateTimeMask
ICCalendar
Graphical Helpers Skins
Internationalization
Predefined Masks
Text Masks
DateTime Masks
Calendar Graphical Helpers
Numeric Masks
Calculator Graphical Helpers
Spinner Graphical Helpers
Decorators
Validator Masks
Skins & Styles
Graphical Helpers Skins
Index Integration with DHTML, JavaScript and AJAX/Web 2.0 applications Supported event onMethod How to create your own mask definitions Developping with IC Suite: Debug mode Integration with DHTML, JavaScript and AJAX/Web 2.0 applications. ICSuite is based on runtime DOM instrumentation technique. Once the page is loaded, ICSuite determines the controls to instrument and enhances them. Form controls are usually recognized by "class" or "id" attributes, according to pre-defined settings. During the enhancement, ICSuite attaches specific event handlers to the original objects and occasionally modifies DOM. This technique allows achieving maximum flexibility and compatibility with server-side technologies. It does not really matter what platform, framework or language was used on the server-side, because ICSuite operated the (x)HTML received by a browser. Once this (x)HTML is parsed, ICSuite becomes active and upgrades the chosen HTML controls. Post-back problem and dynamic changes on the client side An interesting compatibility issue appears on form submission. For instance ICNumericMask allows any number format including locale specific decimal and thousands separator characters. However, server expects a classical number format: no thousands delimiter and a dot as a decimal separator. ICSuite keeps up to date an hidden field with its value unmasked as required by the server. This hidden field keeps the original name that has been given by the developper. Consider an example of a web application using a text field named "income". During instrumentation ICSuite hides this text field (to store the value in compatible format) and creates a new input field with user friendly formatting. You understand that any changes done directly to the control "income" via Javascript are applied to the hidden field and not to the visible one. For example if your application changes the property readonly of the text field "income", it will have no effect, as income is not visible. ICSuite dynamically attaches a "getFacade()" method to each instrumented field. This method returns the facade, the visible field. So, instead of myForm.income.readonly=trueyou should call myForm.income.getFacade().readonly=true When does ICSuite generate an hidden field
If your application sets a new value to an input field that is hidden by ICSuite you must call one of these two functions. Always use these functions when coding JavaScript with Input Components Suite
Examples myForm.myfield.setValue(...); If you'd like to keep your web application operational with and without ICSuite, do something like the following: (myControl.getFacade?myControl.getFacade():myControl).myProperty = ... DOM manipulations with JavaScript AJAX/WEB2.0 applications also take advantage of DOM manipulation without reloading the page. Such manipulation may result in dynamically created form controls: input fields, text areas, etc.. Modern client side scripting standards does not provide a reliable way to be informed of the DOM change. Therefore ICSuite must be explicitly informed of such change in order to instrument newly added elements by calling the process method without parameters. IC.MasterDecorator.process(); Supported event onMethod. You will find bellow the list of onMethod supported by Input Components Suite. It is supporting all onMethods available.
Note. The onChange event is fired by the browser when data is changed by a user and the element looses its focus. However, onChange is NOT fired when the form element value is changed programmically, by JavaScript for instance. Once instrumented with WiseBlocks, many other ways to change the value appears. Naturally, these changes are performed by JavaScript, not the user. In this case "onChange" is not fired by the browser and that can cause a serious inconsistency for the web application. To solve this problem, WiseBlocks simulates "onChange" event every time a changed input field looses its focus.
{ className : "timeMask",
Working with Input Components Suite in Debug mode. ICSuite-2.x.x-custom-settings.js file contains the following setting:
IC.Log.setShowOnError(true); //recommended for development
IC.Log.setShowOnWarn(false); //default value
IC.Log.setShowOnInfo(false); //default value
It means that by default, if ICSuite detects en error in its configuration it will open a pop-up browser window with
the log console with errors, warnings and info messages if there are some.
By default only an error level message opens a window, however, you are free to change this. During development we recommend
enabling error and warning levels. In production all three parameters should be set to false to avoid unexpected collisions.
Nevertheless, you can open the log console at any time by typing in the address bar of your browse the following URL:
javascript:void(ICOpen.Log.show())
Input Components Suite Debugger ![]() |


