See Also: WebGet, Get, Set
Defines a responsive rule for a web property.
WebSetResponsive WebPropertyName ResponsiveDeviceConstant to value
WebPropertyName The name of the property whose value to set.
ResponsiveDeviceConstant One of a list of constants:
Default mode (i.e. desktop mode). This mode is not normally explicitly used.
Default Tablet mode
Tablet mode when in landscape orientation
Tablet mode when in portrait orientation
Default Mobile mode
Mobile mode when in landscape orientation
Mobile mode when in portrait orientation
value The value to set WebPropertyName to.
A web application must adjust to different size clients. Changes in client size can be a one time thing (e.g. loading on a phone vs loading on an iPad) or it can be dynamic (changing between landscape and portrait mode). The process of making adjustments based on client screen size is referred to as being 'responsive'.
Within a view, you define a series of responsive rules. You do this using the WebSetResponsive command. These rules can be applied to any web property (see WebSet) and they get applied when your client size changes. These rules are stored on the web client and are applied without needing to make calls to the server. Therefore, changing the orientation of your iPad or iPhone may change the layout, but it will all happen on the client.
These rule changes are only applied at specific size changes. This can be thought of as a breakpoint. We've chosen the best ones for you. Having rules that adjust to every single pixel size change would be very hard to work with. Even having rules for all of the possible sizes of all mobile devices and tablet devices would be difficult. We don't expect that a developer wants to keep track of all of the different possible sizes where sizing breakpoints should occur, so we have created a pre-defined set. We call these responsive mode settings. Those setting are defined above for ResponsiveDeviceConstant.
These pre-defined sizes should be self-explanatory. It should be noted that changes are applied cumulatively as the screen gets smaller. Therefore, an rmMobile will apply any explicit setting for rmMobile. If there are no settings for rmMobile, it would apply any setting from rmTablet, etc. This list is in increasing order of precedence. If there no responsive settings at all, which is typical, the regular web property’s default value is used. We do not expect that you will change the value of a responsive property using WebSet. If you do, the WebSet always takes precedence.
You won't need to create responsive rules for each of these responsive modes, nor will you need to apply these commands to every single object within your view. A few carefully placed WebSetResponsive rules used in conjunction with piMaxWidth will often be all that is required.
WebSetResponsive piColumnCount rmMobile to 2
“Set the responsive value of column count for mobile devices to 2”
These commands are executed usually once when the object is created. They are sent to the client when a view is loaded. After they have been sent to the client, you cannot change the rules.
// when going down to mobile, change the column count which will force
// controls to wrap to fit within a smaller space
Object oZoomCustomer is a cWebView
Set peViewType to vtZoom
Set psCaption to "Customer Maintenance"
Set piColumnCount to 12
Set piMaxWidth to 760
WebSetResponsive piColumnCount rmMobile to 6
// when running on mobile move the labels to the top
Object oCustomerNumber is a cWebForm
Set piColumnSpan to 4
Set psLabel to "Customer #"
Set pbPromptButton to True
Set piLabelOffset to 90
Set psPlaceHolder to "New"
WebSetResponsive piColumnSpan rmMobile to 2
WebSetResponsive peLabelPosition rmMobile to lpTop
WebSetResponsive piLabelOffset rmMobile to 0
// on mobile, hide this grid column
Object oInvtUnit_Price is a cWebColumn
Set psCaption to "Unit Price"
Set piWidth to 120
WebSetResponsive pbRender rmMobile to False
It is going to take some experimentation to find out the best strategy for building responsive views for all sizes with a minimum number of WebSetResponsive rules. A developer will also have to decide just how exacting they want to be – there are an awful lot of touch devices out there in all different sizes and resolutions. You can probably design pretty nice looking flexible screens with a small number of responsive rules. To go beyond that is possible, but probably time consuming – this is the old 80/20 rule.