If you are considering creating a application that will work well in both the Smart Client and the Web Client (and who isn’t?? ) - I’ve come up with some helpful tips that will hopefully save you a lot of time:
UPDATED Sept 13, 2006
NOTE: These tips are applicable with version 3.0RC4 ONLY. I’ll modify them if the behaviour changes before release.
DO NOT use application.formInDialog() - go to the form instead. You can simulate a dialog - by using a tabless tabpanel - and showing the form in there (don’t forget to use controller.readonly = true for the underlying form before you show the “dialog” tabpanel - or the user can edit the fields underneath the “dialog” tabpanel).
DO use application.getApplicationType() to tell if you’re running in web client or not.
For LISTS - use TABLE VIEW, not Listview. Listview is not supported - and if you use a listview - you’ll see only one row (the height of the body section).
On LISTS - if you set the fields to non-editable - there will be no “record selection” event - that means no backgroundrowcolor, no firing of the “onRecordSelection” event.
On LISTS - in SC the height of the line will be equal the SMALLEST item, in WC its the BIGGEST item (so size all your items with the same height - to remain consistent in SC &WC).
DO USE STYLES for all types of fields/labels
Keep in mind that the size of the underlying form will determine whether or not you will see scroll bars in WC.
When showing forms in tabpanels, make sure that the underlying form is less wide than the tabpanel.
When displaying HTML in a HTML area - DO NOT use your own tags in the HTML - in WC it will render incorrectly. Just use for WC HTML areas - and the style of the label/field will determine the overall font/size
DO NOT use .png graphics - use transparent GIFs if you want them to appear transparent in IE6.
If you have regular buttons that are marked as “transparent” - they will be rendered with the square look (shadow below and right). If you UNCHECK the “transparent” property - then they will render as “regular” buttons in WC.
I think important things to keep in mind when developing for the WebClient also include:
Anchors are not supported on elements
Keep in mind that users can navigate away from your solution (backbutton, open another URL (click on a link, Favorites, type another URL in the address bar etc), close the browser etc.). This is not intercepted by Servoy, so transactions might remain open (untill the Server kills the session) or other things might be left in an undesireable state.
Perhaps Servoy could update this tips section for the rest of us not gifted with the insight…And yes I know it is also in the manual - but with release 3.5.1 out and 3.5.2 imminent I would like these tips as well as the list of things that DO NOT WORK.
The web client has evolved quite a bit since some of the posts in this tread were created so here are some corrections that apply to 4.1 and up.
DO NOT use application.formInDialog() - go to the form instead. You can simulate a dialog - by using a tabless tabpanel - and showing the form in there (don’t forget to use controller.readonly = true for the underlying form before you show the “dialog” tabpanel - or the user can edit the fields underneath the “dialog” tabpanel).
application.showFormInDialog is now supported in the web client. For modal dialogs it opens a modal window in the browser, within the current browser tab. For non-modal, it opens a separate browser window. Very nice.
Anchors are not supported on elements
Anchors are supported now. You first need to turn on anchor support in the Admin console under Web Client Settings.
amcgilly:
The web client has evolved quite a bit since some of the posts in this tread were created so here are some corrections that apply to 4.1 and up.
DO NOT use application.formInDialog() - go to the form instead. You can simulate a dialog - by using a tabless tabpanel - and showing the form in there (don’t forget to use controller.readonly = true for the underlying form before you show the “dialog” tabpanel - or the user can edit the fields underneath the “dialog” tabpanel).
application.showFormInDialog is now supported in the web client. For modal dialogs it opens a modal window in the browser, within the current browser tab. For non-modal, it opens a separate browser window. Very nice.
True, but keep in mind that in webclient the process is continued till the end of your method, while in smartclient the process is waiting till you close the dialog form.
bcusick:
8. When showing forms in tabpanels, make sure that the underlying form is less wide than the tabpanel.
I haven’t found yet what the best wide is for a form on a tabpanel to avoid unwanted scrollbars (webclient).
So in case my tabpanel is 400 x 400, what should be the size of the form that I want to place on that tabpanel without getting scrollbars or unnecessary white spaces?
I notice in WebClient my Dialogs are exceptionally difficult to size properly. Invariably the bottomm of the form gets cut off.
Looks fine in SC. Is there some black art in determining how much of a form will be displayed in a dialog in WC? How can I get th SC and WC dialog to show the same (amount of form) area?
bcusick:
8. When showing forms in tabpanels, make sure that the underlying form is less wide than the tabpanel.
I haven’t found yet what the best wide is for a form on a tabpanel to avoid unwanted scrollbars (webclient).
So in case my tabpanel is 400 x 400, what should be the size of the form that I want to place on that tabpanel without getting scrollbars or unnecessary white spaces?
I too am finding that in WC (Servoy 4.1.1, WinXP, FireFox), even when the height of the form is much less than that of the containing tabpanel I still get vertical scroll bars, and sometimes I get blank space at the bottom of the tabpanel too. Something ain’t right about that. I can usually get around it by making the tabpanel taller than it needs to be, and setting it to transparent with empty border so that even if this makes it overlap other objects on the form, in run-time it doesn’t show.
Servoy, this should be fairly easy to reproduce but if not let me know and I’ll submit a case with example solution.
Can you explain why I have in a newer release than Adrian (build 662 vs build 658), that this setting is gone?
Was it removed for some reason?
On the other hand, I think that this setting anchors must not be on server level, but on solution level.
I think it is better to set this on solution level, just like you’ve done with the AJAX setting.
I that case anchors in WC will only be used for solutions that have been designed for.
Like Nicola said anchors in WC are not fully supported. I was actually surprised they kept this feature in (optional though) when they released 4.1.
So it seems they removed that option again in post 4.1.1 builds (including 4.1.2).
The Anchoring setting was a leftover from the beta stages of 4.1, in which there was experimental support for anchoring in the webclient. Since it was not up to the standards we are after it was removed for now. Unfortunatly, the setting on the admin page was forgotten.
Webclient anchoring is something high on our list though, so stayed tuned…
As for the request for the per solution setting: please file a feature request for that.
As for the scrollbar and tabpanel sizing stuff: you need to take into account all borders and margins of the form and the tabpanel. If you still experience things that cannot be explained, please file a case in our support system with a sample solution displaying the issue.
