3.5.9 isn’t bringing luck to me 
Case 199996 was added
I’m having similar display issues with 3.5.9 in table view. In addition what hasn’t been mentioned are buttons on a Mac in table view. They completely lose their OS X quality of being distinct rounded buttons (when having a height between 26 and 29). I’ve attached a images in Designer and regular ‘browse’ mode. I’m going to have to go back to 3.5.8 until this is resolved…[attachment=0]3_5_9_MacButtonsBrowse.png[/attachment][attachment=1]3_5_9_MacButtonsDesigner.png[/attachment]
john,
what happens if you really set the margin (through the designer or through a style) on 0,0,0,0 for that button?
Hi Johan,
Unfortunately for the button it doesn’t seem to make any difference (it does work for the regular fields in table view). In addition to losing its ‘button shape’, the text becomes weird in the button on 3.5.9. The only text in the button is one ‘hyphen’ or ‘minus’ sign (to indicate to the user that pushing that button will delete that record). With 3.5.9 it becomes three dashes/hyphens/minus signs instead of one and so loses it’s visual meaning. Again this is only in table view. In record view everything (fields, buttons) seems to look fine.[attachment=0]Picture 15.png[/attachment][attachment=1]Picture 14.png[/attachment]
Just wanting to throw my voice into the mix that some aspects of bordering on table elements is now messed up in 3.5.9 and 4.1.1.
On a normal table view form, I use a Special Matte border to give a dotted line beneath the entire row. (As an aside, it would be way cool if stylesheets supported dotted or dashed bordering. They don’t, so I’m stuck with setting it on an element by element basis…) On certain types of fields, this no longer displays the same as it did in 3.5.8 or 4.1.
Specifically, comboboxes, checks (with a valuelist), dates, [text/html] area fields, and radios double the border specified if the border is one of the following types: Etched, Bevel, Special Matte. In the pictures below, I did all the examples with Special Matte, but they work more or less the same with the other two as well.
Attached are two pictures to illustrate this:
Screenshot #1:
All fields in this picture have the exact same border property set. It is “SpecialMatteBorder,0.0,0.0,1.0,0.0,#000000,#000000,#999999,#000000,0.0,1.0”. The field display types are (in order from left to right): text_field, date, checkbox without valuelist, checkbox with valuelist, textarea, and combobox. Notice how only the text_field and checkbox without valuelist render the border correctly. All the others seem too thick.
Screenshot #2:
Here we see three date fields with different borders. Column 1 has the same border as above. Column 2 has a 1.01 size for the bottom border. I did this so that Servoy would be forced to space out the doubled border a little bit to make it obvious. Column 3 has a 0.5 size for the bottom border. When 0.5 is doubled we end up with 1.0, which is the border I wanted to begin with.
Even though the screenshots are from a Mac running Leopard, the same behavior was replicated on a WinXP box. Note: I tried making sure the margins were 0px using a style class as well as punching it directly onto the element. There was no difference in the end result.
Is there more information I can provide to clarify the issue?
One more issue:
Can anyone confirm that this works for them: [fix] case 80394 Webclient: Forms with a navigator show unwanted scrollbars ?
In my case I still see unwanted scroll bars on all forms in web client where a custom navigator is used.
Troy,
When I see your picture, I see that the first city is nog on the same height as the second city (look at Amersfoort)
I noticed also that sometimes a field/label is 2px higher than designed.
I guess in smart client you don’t have this difference
Martin
Martin,
Those screenshots actually are from smart client. I had increased the height of the row so it was easier to see the bordering issues, normally I have the row height set about 5px less.
The reason for the two cities not lining up is that one is a text_field while the other is a text_area. Since I never use text areas in a table view, my styles sheet doesn’t have a margin on it that would make them align better.
So while the screenshots may look like they have other issues, the only ones that I can’t get around at this point are the double bordering.
One of the below fixes seems to have broken a release that was stable in 3.57 and 3.58. It’s just that it’s forcing a save before a sort, and while I know saving before a sort (when unsaved changes are present) is required since 3.1, never did 3.5.8 didn’t care about this instance apparently. We’ve rolled back to 3.5.8 for now, but on top of the problems I’m having with my newest solution (see forum post http://forum.servoy.com/viewtopic.php?f … 277#p62093) I’m not in great standing with my customer. Any help would be VERY appreciated.
Changes:
[fix] case 195122 Open form in dialog for the second time exits find mode.
[fix] case 190986 form in dialog and currentcontroller issue
[fix] case 190951 strange behavior on form in dialog
[fix] case 199556 showRecord, does not take over the currentSelectedIndex in some situations
The reason I believe it’s one of the above is because I’m in form in dialog, have just performed a find, and probably use showRecord too – definitely controller, though not currentcontroller.
ellenmeserow:
It’s just that it’s forcing a save before a sort, and while I know saving before a sort (when unsaved changes are present) is required since 3.1, never did 3.5.8 didn’t care about this instance apparently.
Sorting always saves (unless auto-save is off, but then sort is ignored if there are unsaved records), since Servoy leaves sorting to the database, it has never been otherwise
What I’m seeing is an error in Developer (caution triangle ! in the lower left) that says that the sort couldn’t happen because there were unsaved edits to one of the records. And I’m relying on the sort for a particular method. In 3.5.8 this didn’t happen?
But this is less important than the post in viewtopic.php?f=8&t=12277#p62093. Can you help with that? I’m chasing these TEMP_ tables that Servoy can’t drop for three days now…
Does Servoy 3.5.9 support removing and/or modifying the menubar at the top of the window in smartclient, or is it necessary to purchase a separate plugin to do this?
Dean Westover
Choices Software, Inc.
For 3.5.9 you’ll need the menubar plugin from IT2BE.
This same plugin is standard in 4.1 (as far as I could see it is exactly the same; no difference found yet). So for Servoy 4.1 you don’t need to purchase this menubar plugin
Is it just me or is the dialogue not closing in webclient worse in the version?
My modal dialogues dont close the first time now. Before it only happened the second time.
I think this has been fixed in 4.1.1.
Is there any chance a fix could be done for 3.5.X?
Thanks
David
David,
i cant reproduce this at all.
I tested it in 2 browsers: FF3 and IE8, i have a form with 2 buttons that both display a modal dialog in the same container with 2 different forms.
And i can click 1 button multiply times or mix both buttons, so showing a dialog with formX close it show it with formY close it and so on.
So if you have a reproducable test case plase make a case for that in our support system.
Thanks Johan,
I was in safari. I will retry in Firefox on mac. as long as it works in one browser, i can live with issues in another.
David