What SDK fling version are you using? Can you try Fling 6 we pushed yesterday (html-client-sdk-6.5.0-4507438.zip)? Because we fixed dialog size issues.
If it is still not working with Fling 6 please describe the problem in details, thanks!
thank you for your response.
This problem has been resolved in the new sdk.
There is a problem has not been resolved, the right side of the pop-up window has been a scroll bar.
Do not know whether this issue is solved in the next version of the sdk.
If it is solved,please tell me,thanks again.
1 person found this helpful
What do you mean by the fact that there is a vertical scroll bar - when you open the dialog there is such a scroll bar or a scrollbar appears when you resize the main window and that scroll bar remains even after restoring the original size?
In additon cold you reproduce the isssue by modifying some of the samples from the sdk (for example there is such a functionality in chassis-summary.js of chassisA sample)?
I has tested this issue and found that I set the height above the maximum height provided by the interface.
Pop-up window has the maximum height now?
Later, the pop-up window will be the same as pop-up window of fling's "add host"?
I'm sorry but I still cannot get it quite well.
Is it possible for you to modify sample ChassisA so that we may reproduce the issue at our end?
thanks for your reply!
I'm sorry that I didn't have explained the problem clearly. Now I hava sort out the issue.
I want the content to be displayed correctly and no scrollbars appear. But there are some issues with the display.
I have two monitors to display.The resolution of a display is 1440*900 and another is 1920*1080.Now I use these monitors to show the pop-up window.
I use the API "WEB_PLATFORM.openModalDialog(title, url, 872, 485, null, 'no', false); " to create a pop-up window.
In the 1920*1080 one, it is a normal display as shown in Fig.
In the 1440 * 900 one, there is a problem with the display, a scroll bar appears, as shown in Fig.
And In the 1920*1080 one, I used another parameter, "WEB_PLATFORM.openModalDialog(title, url, 872, 486, null, 'no', false); ", to create a pop-up window.
The height is changed from 485 to 486, then there is a problem with the display, a scroll bar appears, as shown in Fig.
I found that the height of the pop-up window appeared the maximum and the maximum is different when the monitor's resolution is different.
the pop-window opened by API will be the same as the one of fling-web-client like the shown of under picture.
There are some points that I want to know.
First,the close button of upper right corner of the pop-up window can be setted to show or hide?
Second,can I move the pop-up window by pressing the title bar and moving?
Third,can I change the size of the pop-up window by pressing the icon of lower right corner of the pop-up window and moving?
If you can do so, please tell me about how long I can use,thank you.
I have some ideas.
I want to add an icon before the title of pop-up window and I want to change font size of the pop-up window's title.
I have writed a method to open a dialog to show loading message, I want to mask the all content of the pop-up window include the title bar when the loading dialog is opened.
But it only masks the content area now, the title bar of the pop-up window is not masked as shown in Fig.
If you can do so please tell me, thanks a lot.
* scrolls - the iframe is all yours, you can use css in order to remove any scrolls (by modifying the size of the content)
Even you have pointed that 'In the 1920*1080 one, it is a normal display as shown in Fig.' I see it is not normal since there is a horizontal scroll bar at the bottom.
An action item for me is to verify the framework angainst maximum sizes that you have mentioned
* close button - as it is mentioned in the 'Known issues' section of the Getting_Started_with_HTML_Client_SDK.pdf file from the Fling it is always displayed.
* move & change size by dragging - currently not supported. I have asked the team that develop the component if they have any future plans about this
* icon in the dialog - they are currently supported for dialogs that are shown as a result from an action invocation (see Getting_Started_with_HTML_Client_SDK.pdf ) , not for dialogs opened by the general 'WEB_PLATFORM.openModalDialog' functionality
* font size - not supported since this is a dialog from the platform and all platform dialogs are supposed to be uniform
* loading message will not be allowed to overlay the whole dialog since this will interfere with the user capabilities to abort an action at his/her will. In addition if for some reason the plugin becomes unresponsive in the 'loading' state then the whole application will be unusable. This is something that should not be allowed in any case.
I'll use your feedback/questions and bring them to the attention to the PM/PO of the SDK.
So really thank you a lot!
thank you for your patience to answer my question.
Your answer has solved many of our problems, but when I read your words, I thought of another problem.
You mention that "font size - not supported since this is a dialog from and all platform dialogs are supposed to be uniform".
I know your mean is that all dialogs which vmware supplies for plugin development like us must be uniform.
As a developer, I know there are two kinds of dialogs, one is used by VMware, and the other is provided to us through the interface, their code and structure are diferent so that they have different functions and styles.
But as a consumer,they may not know that,they may think all the dialogs will be the same.
So there is a problem,the vmware'dialog(Right click a host and select the "Add a new VirtualMachine",a new dialog will pop-up)will not close when click the area next to the dialog box.
But when users use the plugins,they can close dialog by clicking the area next to the dialog box,this will confuse the users.
For users, they use the dialog box appears different, become inconsistent, and it may affect the user experience.
I just mentioned one of the differences.
I do not know whether the dialogs created through the interface are the same as those used by VMware at the end.
If you have ideas please tell me,thanks again.
> I know your mean is that all dialogs which vmware supplies for plugin development like us must be uniform.
> As a developer, I know there are two kinds of dialogs, one is used by VMware, and the other is provided to us
> through the interface, their code and structure are different so that they have different functions and styles.
Yes and No - we strive to provide uniformity between all the dialogs across the application and to the most possible extend share the same code base.
One of the key difference between the dialogs for the plugin and ones for the core product is that the content of the plugin dialog is in an iframe in order to achieve isolation. For example this leads to the consequence that there are no default buttons (like ok/cancel). Such buttons would be outside the iframe so it would be more intricate to call functionality within the iframe. In that case the plugin writers have to implement all the necessary buttons (being they default or special ones) in the iframe. We don’t consider this an issue since the iframe gives unlimited flexibility and is up to the plugin writer. Having a close button at the top right corner of the dialog is more natural since its purpose is just to close the dialog without interacting with the iframe contents.
Some of the dialogs are in fact wizards - another type of modal objects (create a vm example). They may exhibit a little bit different 'internal' behavior. The SDK does not provide wizards, but again this is not considered an issue since the provided iframe gives the ability to do whatever is needed, the iframe content is up to the plugin itself.
The HTML client is work in progress (WIP). New functionality, components, styles etc. are continuously added, modified improved. Some areas require migration to use the new stuff which migration is done gradually. This is the case with the dialogs (modals). The plugin dialogs are updated to the most recent component that is available. At the same time there are parts in the product that use the old one (some of them are even jQuery-ui based). This is yet another reason that may lead to a difference that you may see. But the final goal is to have an uniform HTML client and SDK to the most possible extend.
Please use the latest Fling release. We provide new Fling releases frequently. The new release adds new functionality, bug fixes etc. For example in the latest one I cannot see the behavior that you describe – clicking outside the plugin dialog closes the dialog. I have tried with add/edit Chassis A sample and the dialog remains opened if you click anywhere outside.
5) Missing features:
There might be missing features. Please be vocal about them. All the requests will be considered with PM, UX, architects and triaged and the approved ones implemented. Also feel free to share any inconsistency that you have found (as you have already done about the close dialog functionality)
These are my thoughts on the subject.