<mx:advanceddatagridcolumn headertext="Parts Ordered?" width="80" datafield="parts_ordered" fontweight="bold">
<mx:itemrenderer>
<mx:component>
<mx:hbox disabledoverlayalpha="0.0" enabled="false" horizontalalign="center" verticalalign="middle">
<mx:checkbox selected="{data.parts_ordered.toString() != 'F'}">
</mx:HBox>
</mx:Component>
</mx:itemRenderer>
</mx:AdvancedDataGridColumn>
I'm a developer and code junky. I like languages, and the premise behind how and why people write the code that they do.
Thursday, July 17, 2008
Aligning a checkbox in a Flex Datagrid
When you need to align a checkbox within a Flex based Datagrid the best way to do it is to center it with a Horizontal Box as so
Tuesday, July 15, 2008
BlazeDS - Filtering out your own message
Recently I created a record management framework for a RIA that I've been working on for my employer.
The idea behind this is that as soon as an individual opens a record for possible editing he locks the record from being edited by any one else.
Using Flex/BlazeDS this was rather straightforward. I created a new channel called recordMangement and sent all lock/unlock requests to it.
One of the options that I wanted to do, however, was to filter out the messages that I was sending so that the event handling would be efficient and straight forward.
My first thought was to use the connection ID that is created when you connect to the DS channel. I would then just ignore those messages that came from the same ID as the one I have. This turned out not to be as effective as I liked as I came to the conclusion that the connection ID was an ID that was specific to the physical connection itself and not the logical connection. Therefore it was possible for the physical connection to be reset between the sending and receiving of the event.
In the end it became more efficient to create a unique ID instance using the UIDUtil.createUID function which became a constant value for all communications that I establish and then use the selector function to designate a filter for the my consumer.
consumer = new Consumer();
consumer.selector = "(from <> '" + uid + "')";
The idea behind this is that as soon as an individual opens a record for possible editing he locks the record from being edited by any one else.
Using Flex/BlazeDS this was rather straightforward. I created a new channel called recordMangement and sent all lock/unlock requests to it.
One of the options that I wanted to do, however, was to filter out the messages that I was sending so that the event handling would be efficient and straight forward.
My first thought was to use the connection ID that is created when you connect to the DS channel. I would then just ignore those messages that came from the same ID as the one I have. This turned out not to be as effective as I liked as I came to the conclusion that the connection ID was an ID that was specific to the physical connection itself and not the logical connection. Therefore it was possible for the physical connection to be reset between the sending and receiving of the event.
In the end it became more efficient to create a unique ID instance using the UIDUtil.createUID function which became a constant value for all communications that I establish and then use the selector function to designate a filter for the my consumer.
consumer = new Consumer();
consumer.selector = "(from <> '" + uid + "')";
Subscribe to:
Posts (Atom)