FormItem problem

Hi!

I just recently got a notice on my last post from Neil that when using FunFX a null pointer exception is thrown when any form item's label in a form is null as shown in the first listing. Neil pointed out that it was also happening when the label was set to an empty string.

<mx:form>
<mx:formitem label="Form Label">
<mx:label id="lLabel"/>
</mx:formitem>
<mx:formitem>
<mx:textinput id="tTextInput"/>
</mx:formitem>
</mx:form>

Neil pointed out that it was something to do with the FunFX and FormItemAutomationImpl interaction. And that one need to set all the form items labels to a non empty string. And that using whitespaces as label affects the layout. He suggested a nice workaround until a fix with the FormItemAutomationImpl is done. And that is to set the label width to 0.

<mx:form>
<mx:formitem label="Form Label">
<mx:label id="lLabel"/>
</mx:formitem>
<mx:formitem label="" labelWidth="0">
<mx:textinput id="tTextInput"/>
</mx:formitem>
</mx:form>

I have created the error for my own, and the reason for the error is as Neil said. The FunFX uses the automation framework from Adobe to create string id of the display objects that it interacts with. And this method in the FormItemAutomationImpl.as as displayed in the following listing. When the label of the formitem is null, there is no check that will prevent the method to call the length method of the label, which might be null.

private function getItemAutomationName(child:IAutomationObject):String
{
//Have cut down the method
result = (label.length != 0 ? label + ":" + child.automationName : child.automationName);
// More in the real method
}

I have not yet been able to check wether it is possible to just add a null pointyer check in the method. But this will probably implie a change in th corresponding method that creates an object from the string id.

I hope this will help people in the same situation as Neil. And I will see if it can be fixed. But so long you will need to do as Neil suggested and set the labelWidth of the form item to zero.

Thanks alot Neil, for this valuable tip and solution!

Some problems and solutions when using FunFX

Hi everyone.

These past days I have used some time trying to set up FunFX for the project I am on at work. I have said to my self earlier (because some people have had some problems with custom components) that I would write a post about this. Because I do no know to much about this area, how FunXF actually handles, I have not had the time to do this yet, but I asure you that it will come.

So instead I will use this post to talk about some of the problems and solutions I have had the last few days.

First of all double clicking a row in a datagrid made me a bit frustrated today, because it would not replay the action that I wanted to do. The following line was what I tried to do (the datagrid contained a row with a column that held the value "Person".

@ie.data_grid("name").double_click(:item_renderer => "Person")

After some error checking it seems that you must select the row before doing a double click. The following lines works perfect. I have not yet found a good reason why this behavior or a better solution if people think it should be handled better.

@ie.data_grid("name").select(:item_renderer => "Person")
@ie.data_grid("name").double_click(:item_renderer => "Person")

Anther thing I has some trouble with was accessing elements of an repeater when there is an hierarchy of display objects within the repeater, then the number of the single element I wanted waas multiplied with the number of parents abow. In the following example I would get 4 tLabels and 4 tData.

<mx:repeater id="rep" dataprovider="{}">
<mx:vbox id="vboxen">
<mx:hbox id="hboxen">
<mx:textinput id="tLabel" text="{rep.currentItem.label}"/>
<mx:textinput id="tData" text="{rep.currentItem.data}"/>
</mx:hbox>
</mx:vbox>
</mx:repeater>

I am still testing the solution (and will probably put out a new version of FunFX in the next days), so I am not completely sure that it is the best solution. But I have up until now used the objects automationChildren when try to reach the children, but this seems to multiply children of repeaters and like. So I have switched to used the rgular children instead, and for now it seems to do the trick, but I still have to test that all other displayobjects still are supported.

With the new solution the issue where you had to write the repeater and then the object you wanted is now gone. Now the repeater will not exist as an display obejct. So you write as the last bulk says.

@ie.repeater("rep").text_area("tLabel")[0].input(:text => "Test") # This is now wrong

@ie.text_area("tLabel")[0].input(:text => "Test") # This is correct

But so far I am able to do automatic functional testing of a registration form and to ensure that the calculation response from this registration is correct. Due to low speed these tests are not run too often, but I will try later to include the tests in the nightly build.