[Isomorphic]

Ah yes, sorry. Create a .zip and email it to support@isomorphic.com, referring to this forum thread.

[wrussell]

OK, done - look forward to your comments

[Isomorphic]

Thanks very much for the file - it made reproducing the issue very simple. And great work on the the color picker widget - it's very very nice.

The problem is that you're calling 'setLeft()' / 'setTop()' on the crosshair image and passing in a non-integer value.
If you call parseInt() on the value before calling setLeft() / setTop() the problem should go away

Let us know if that doesn't fix it
Thanks

Isomorphic Software

[wrussell]

That worked fine, thanks for the help.

The picker widget is now complete and I would like to make it available to the community. Should I just email a zip to the support address? Also, what about documentation? I have documented the attributes with comments in the code, following the technique used in your existing ColorPicker class, but I couldn't see how methods are documented. Also, in keeping with what I observed from the ColorPicker code, I have been through and renamed my methods and variables, placing an underscore before the ones I consider private (imagine how much fun that job was!). Is this actually a standard in SmartClient or have I jumped to conclusions?

I have also created a Word document, describing how to use the widget (rather than just a description of the individual variables/methods). Should I provide this as well/convert it to text/whatever?

I know it's early days, but it would be good if there was a more defined process for submitting code...

Thanks again for the help,

Wayne

[Isomorphic]

Hi Wayne
The whole team here really appreciates your contribution with this. As we mentioned before, the widget looks great, and the inclusion of documentation is going to be invaluable.

To answer your questions:
If you browse the "source" directory of the SmartClient 6.0 LGPL release, you will see the documentation for classes, methods and attributes is included inline in the source files in what we refer to in-house as 'jsdoc' format.
Documentation is written in comment blocks which look like this:

//> @[document block type] [value]
// Description
// @[various flags]
//<

We will probably provide a public document on writing these standard docs at some point, but for this particular widget the following information should get you going.

Class / Widget overview information is typically put into a single class definition block. The ResultSet class definition is a good example of this - open source\client\application\ResultSet.js, and search for "@class ResultSet".
Your widget overview would typically go in here (so if you want to shift it across this would be fine, though we'd also be happy to recieve your word document and perform the conversion here if you'd prefer).

Descriptions of instance-methods are identified by the "@method" flag. The Canvas class contains a large number of examples of this - for example canvas.setLeft().
The @param flags (after the method description) allow you to explicitly doc the parameters for the method, and should be written in the format:

// @param paramName (type) description

You can also document what the method returns via @return - which has the format

// @return (type) description

For now you can ignore @visibility / @group flags

In terms of the "_" prefixed methods and properties: This is indeed the standard SmartClient convention for internal attributes and methods. You don't need to do this, but provided a method is only to be used internally within the Class (and not available as a public API) it is appropriate.

We agree that we need a better process for code submission - and improving this flow is on our roadmap.
To get the component to us, for now we'd suggest you send us the zip file at the support address and we'll do a quick review and then make it available on the forums.

Once again - thanks very much for making your work available to the SmartClient community.

Regards
Isomorphic Software