[Isomorphic]

We'll take a look at the loading dialog issue. On the form issue, we'll need a way to reproduce the problem, as there doesn't seem to be anything similar happening in any of the samples.

[jornn]

We are also seeing the same issue as described by ssssteffff. This was seen when testing with FF 18.0.1 and SmartGWT 3.1p Jan 22nd 2013. Issues not seen on FF 10 + 17.

Issue 1:
Our window dialogs are showing a strange shadow appearance. See attached image.

Issue 2:
Also, we are seeing a second issue with forms with many radio buttons. The radio buttons are not selected in some cases. Please see second attachment.

[Isomorphic]

We see the problem with shadow appearance (strange gaps in the shadows) and are working on it.

We haven't seen a problem with radio button selection and it's not clear from your screenshot what the problem is. Can you show us a snippet of code containing a form with a radiogroup that we can run on our end and describe how to reproduce the problem

Thanks

[jornn]

I tested todays (Jan 23rd) SmartGWT 3.1p and the same two issues remains.

I will see if I can come up with an example/short code on how we are loading/using RadioButtonItems in our app.

Tx.

[jornn]

I tested todays (Jan 23rd) SmartGWT 3.1p and the same two issues remains.

I will see if I can come up with an example/short code on how we are loading/using RadioButtonItems in our app.

Tx.

I attempted to create a standalone test which could reproduce the issue but have been so far unsuccessfull. I will continue to work on it today since this is our showstopper at the moment with FF 18.

Not sure if I've mentioned it so far, but this issue only shows up in production - if running inside eclipse, the radio button panel works like it should (no empty/not selected radio buttons).

[jornn]

I have been able to find a workaround for the Radio Button Group issue:

1) Call rbItem.setValue(null) before updating the radio button to some other value.

I attempted this because I saw that the radio buttons always set themselves to the proper value the very first time the user selected a resource which set the radio buttons to some value. Every time after the first time they were sporadically setting themselves.

So, I tried this:

// bug workaround
rbItem1.setValue(null);
rbItem2.setValue(null);

// set rb values:
rbItem1.setValue("D");
rbItem2.setValue("M");

... and that worked...

[ssssteffff]

We'll take a look at the loading dialog issue. On the form issue, we'll need a way to reproduce the problem, as there doesn't seem to be anything similar happening in any of the samples.

I think schen found the reason of the form issue in his new thread ( http://forums.smartclient.com/showthread.php?p=98882 ). If it is relevant, thanks to him :)

[jornn]

I think schen found the reason of the form issue in his new thread ( http://forums.smartclient.com/showthread.php?p=98882 ). If it is relevant, thanks to him :)

... I don't see how he found the reason for the shadow issue?

[ssssteffff]

... I don't see how he found the reason for the shadow issue?

I meant the too-tall form issue, not the shadow one. I reported this issue but couldn't find why my form was too tall. Schen found it was related to the showIfCondition.

[edulid]

I'm regression testing our app against the Jan 29th SmartGwtEE nightly against Firefox 18, and I'm seeing that TextItems (FormItems) that are disabled aren't drawing - they don't appear onscreen. Has anyone else seen that behavior?

Thanks!

Yes, same happening to me!

[cjustice]

I'm also seeing this in IE8, using the January 30th build. TextItems that are disabled are not rendering in IE8 or Firefox 18.

Is this being looked at?

I'm regression testing our app against the Jan 29th SmartGwtEE nightly against Firefox 18, and I'm seeing that TextItems (FormItems) that are disabled aren't drawing - they don't appear onscreen. Has anyone else seen that behavior?

Thanks!

[Isomorphic]

We're not reproducing the problem with disabled TextItems failing to render. We've opened a new thread for this: http://forums.smartclient.com/showthread.php?t=25277

If you can show us how to reproduce the problem (in that thread) we'll take a look.

Regards
Isomorphic Software

[andyx1975]

This is not Firefox related... but it happended due to the ff changes in nightly builds. The rich text Item is not editable anymore in Chrome and Opera. On Firefox and IE it works. I am Using Nightly 3.1 from 31.01.

 txtText = new RichTextItem( CItemSupplyNews.txt, "Text" );
                txtText.setShowTitle( true );
                txtText.setWidth( "*" );
                txtText.setColSpan( 1 );
                txtText.setHeight( 300 );

[freon]

Are you going to expose the nightly builds in the smartclient Maven repo? We can't depend on the nightly buids in our project if it is only "link to some jar" somewhere on the web.

[skomarla]

Are you going to expose the nightly builds in the smartclient Maven repo? We can't depend on the nightly buids in our project if it is only "link to some jar" somewhere on the web.

We have the same issue. I usually end up downloading the jar and adding it to our internal maven repo (sonatype nexus). its pretty easy to do it you want to give it a shot. http://www.sonatype.org/nexus/go