7/1/2025 5:34:33 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss the use of the SalesLogix Web Platform, Client and Customer Portals, and the Application Architect (For version 7.2 and higher only). View the code of conduct for posting guidelines.
|
|
|
|
Is it possible to disable the dimming effect caused by postback?
Posted: 12 Nov 09 8:46 AM
|
Hi,
I have a form in a dialog workspace, which contains buttons to effect other controls on the same form.
I dislike, however, that clicking these buttons causes a split-second dimming/greying of the screen; it serves little purpose other than to be distracting.
Does anyone know if it's possible to disable this effect so that my buttons can post back without the screen dimming?
I only want to disable the effect in the context of the dialog too, not permanently or throughout the client.
Thanks,
Alec D |
|
|
|
Re: Is it possible to disable the dimming effect caused by postback?
Posted: 12 Nov 09 12:31 PM
|
Although you may think that it serves little purpose, it does have a reason to be there.
The main reason for it is to prevent further interactions between the user and the system while the Changes are passed to the server.
If you allow the users to continue working on the app, they may trigger another post back (from a different control event) and at that point, where would your ViewState be sitting at?
Although it seems as if it is not possible for users to do so, trust me, I have seen them do that. I have seen them click on buttons before the whole view was loaded and thus break the load, break the app, etc. No one was able to reproduce for months, until we finally got there on person and watch the fingers clicking the mouse button....
That being said, if you dislike the posting to the server, why don't you implement your code as client side Javascript?
Sometimes us as developers disregard the Latency that users in the field have. So, on our system clicking on a button that enables/disables others takes about a second, so no big deal. Then once you get a user that has a 3 to 5 second latency time, every click on a button or control that does a post takes an huge amount of time. As an example, once I had to redesign a Insert Contact form that had been built for a client on which pretty much every control forced a Post Back. That meant that to complete the form, the user may have needed 10 postbacks. Multiply that by their latency (which the developer on his fast machine never accounted for) and you can imagine how unhappy the end users were with the result.
|
|
|
| |
|
Re: Is it possible to disable the dimming effect caused by postback?
Posted: 17 Nov 09 5:25 AM
|
I've got another issue further to this.
First I'll explain more about what I'm trying to achieve. I've got a number of buttons, in rows. Each row of buttons also has a label on the end. Pressing a button adjusts the value of it's related label according to the button's associated integer value, so for example, the button on the left of the row writes a smaller value in to this label than the button on the right of the row. Clicking a button changes its color to reflect its selection.
I built a simple prototype of this (in VS, outside of SLx) and it works fine as an ASP (.aspx) page with the controls contained in an AJAX UpdatePanel to reduce response time.
The issue I'm having I think extends from my lack of understanding of how SalesLogix Web handles postback events and/or relevent to SmartParts in the DialogWorkspace. When I applied the same logic to my Dialog SmartPart, the following happened:
i) PostBack time went from effectively instant, to over a second. I accept this could just be server lag however, my real issue is the next one, though I wonder how much additional information it's submitting at this point?
ii) It seemed that doing a PostBack was refreshing my form (obviously) but also forgetting which of the buttons had been pressed in previous instances. That is, pressing one button reset all the others.
I could put in a whole load of Session variables to persist button presses between PostBacks, or I could do this whole part with HTMLInputButtons and Java, although my experience so far is that programmatically generating client-side controls then responding to their actions server-side without per-event PostBacks would be very complicated, and a nightmare to debug.
Either way it seems to be there'd be a better way of doing this, and I don't understand why in my prototype this stuff 'just works'. I imagine the difference is that in my prototype, the AJAX UpdatePanel means the whole page isn't being posted back every time, whereas in SalesLogix Dialog Workspace, it is doing a full page unload and reload?
Sorry this has really got me confused  |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|