|
| If a SlidingMenu is written inside a table cell and this
cell is aligned=center, then the content inside the SlidingMenu will
move to left align at the center. This problem can be solved by
writing another table inside the first table cell and
then put the SlidingMenu inside the nestet table. Problem is not yet
examined. |
|
|
| There seems to be a problem with the right side of a SlidingMenu
if 2 conditions are met, 1) the width of the SlidingMenu is set in percent
AND 2) there is a scrollbar in the Group that closes. Problem is not yet
examined. |
|
|
| If your VS.NET IDE Designer is in
Grid layout (as opposed to Flow layout), it is possible to add
a Toolbox Item (here the SlidingMenu) in 2 different ways: 1)
dragging the item from the Toolbox to somewhere on the
Designer surface and 2) marking the item and draw a rectangel
on the Designer surface (only in Grid layout). If you try to
add the SlidingMenu using method 2, your VS.NET IDE will
crash. This happens then the SlidingMenu tryes to write
IntelliSense statement completion (xmlns:wm-attribute to the
BODY tag) to the HTML source of your WebForm, in fact it
happens then SlidingMenu tryes programmatically to switch the
active tab from Design to HTML of your WebForm in order to insert the xmlns:wm-attribute. I do
not know what triggers the fatal error in method 2
as opposed to method 1. The solution is to drag the SlidingMenu instead
of drawing it. |
|
|
| Then vertically aligning content
within a table cell different from "top", a SlidingMenu inside
this table cell will not vertically align within the table
cell if the height of the table cell is changed eg. upon
browser resizing. The problem comes from what seems to be
a fact that if an element has height or width style set, the element will not vertical align within
a table cell, further examination is necessary to qualify the situation. |
|
|
|
This problem will show itself in case you have a SlidingMenu there only say the first Group have a GroupHeader
different from zero height. If then you put a HTML table inside the GroupCanvas of the next Group and expand
that table to a 100% height and set a border on the table, it is possible to see that the GroupCanvas should have
been one more pixel up then the Group is open. However, even if you work with GroupHeaders of zero height, you may never
encounter this problem. Problem is not yet examined.
|
|
|
| Then SlidingMenu runs in full
development mode <SlidingMenuStyle
ClientAPIInclude="ExpandedWithDevelopmentInfo" ... />, you
will be told if the height of the SlidingMenu is less than the
sum of the headers plus the border around the SlidingMenu.
This error message will also display if you press the Back
button in your browser and comes back to a page there the
SlidingMenu is loaded into an IFrame. In that case the error
message should not show. The problem does only exists in full
development mode and therefore not in your production code.
However my solution of using JavaScript to tell you if the
SlidingMenu is not high enough to encompass the GroupHeaders
is in itself a bad solution and is likely to be solved by
design in the next version (as I in the next version hope to
implement a general exception
scheme). |
|
|
| The Client API events wm_3_onGroupOpened, wm_3_onGroupClosed and wm_3_onPositionChanged are not instantiated (client side) upon PostBack. It means that a SlidingMenu can have problems initialize correct GUI upon PostBack, for instance you could have different images in the GroupHeader depending whether the Group are open or closed, but since the SlidingMenu does not raise these events upon PostBack, there is no intrinsic way to find out if a certain group is open or closed initially after PostBack. The first time the SlidingMenu change after PostBack, everything works again, however to initialize correct GUI it can be necessary to use other Client API functions setting up the GUI yourself, there is a solution in the SlidingRSS example, look for the InitializeLocal() function in the bottom of the JS (JavaScript) tab. Problem is not yet examined. |
|
|
| Then submitting a page (Web Form), SlidingMenu default remember which Group was open (can be disabled eg. declaratively <SlidingMenuStyle RememberOpenGroup="False" ... />). However, then the second time a page is submitted, SlidingMenu forgets which Group was open. Problem is not yet examined. |