kind of difficult to explain... dialog in front of another window... Thanks for your help!!!

  • Thread starter Thread starter Daniel Walzenbach
  • Start date Start date
D

Daniel Walzenbach

Hi,

I have to following problem: Imagine some kind of data the users of my
application got to see. Based on this data they decide if it concerns them
and they want to edit the data or if does not concern them in which case
they should not be allowed to modify the data. To accomplish this behaviour
I thought about opening the page containing all the data and opening a
dialog window "above" ( <script language='javascript'>window.showModalDialog
(... ) which they have to answer first. Trouble now is that I don't know
when to open the dialog window since opening a dialog stops the underlying
page from execution which results in an open dialog combined with a white
underlying page. I would also be glad if I could somehow present the data to
my users and open the dialog on their first click somewhere on the page (of
course regardless where they click on - must be some kind of <href> all over
the page or so).

Does anybody have any idea? Thanks a lot! I appreciate your help!!!

Daniel Walzenbach
 
If you want the underlying page with a dialog on top of it, that is, no
white space page, consider using
page.controls.add("<script>alert('i can see page')</script>");
Did that answer your question?
 
Hi Daniel,

You could also use the Page.RegisterStartupScript method to dynamically
emit the script:

String scriptString = "<script language=JavaScript> alert('Please
confirm!');</script>";
if(!this.IsStartupScriptRegistered("Startup"))
this.RegisterStartupScript("Startup", scriptString);

This method emit the script just before the closing tag of the Page
object's <form runat= server> element. This make your customers able to
read the page underlying the dialog.

Regards,

Felix Wu
=============
This posting is provided "AS IS" with no warranties, and confers no rights.


--------------------
From: "Daniel Walzenbach" <[email protected]>
Subject: kind of difficult to explain... dialog in front of another
Click to expand...
window... Thanks for your help!!!
 
The second part first. Do not include any onclick event handlers for page
elements but create one for the document. In this way, by virtue of event
bubbling, the document onclick handler gets all the click events. You can
use the window.event.srcElement.id to determine which element was clicked
and handle the events that you might have otherwise assigned to the
individual element click handlers. Handling onclick this way allows you to
capture the first click, post your question to the user, and continue on.

Now, how can you post your question to the user before they take other
action on the page? There may be better or easier ways than this; I'm sure
that if there are, you'll get plenty of suggestions. How I would probably
do it, given just a few minutes here to consider the options, would be as
follows.

Load your page with the controls that you do not want the client to use
turned off. Create a DIV that presents the data, sort of in the form of a
splash screen; in other words, this DIV is centered in the client area and
on top of all other page elements. Make this DIV the first element of
client code, immediately after the BODY element.

In this DIV you can pose your question and enable the controls within the
DIV to either edit the data or to click to "close" (really to hide) the DIV
and allowing the client can continue. When the client performs acceptable
action - for instance, they either edit or "close" the DIV - then you enable
the controls on the rest of the page and then hide the DIV (set it's
visibility style attribute to "hidden") .

I have done this in the past as a splash screen, leaving everything disabled
until the page load is complete, then turn off the splash screen DIV and
enable the rest of the page. The page loads just fine while the splash
screen is displayed. I don't suppose adding the data editing functionality
to the splash screen DIV would present any insurmountable obstacles. I do
believe this would be a better method than presenting it on their first
click as you propose. Clients are funny about wanting "expected" behavior
when they click something... Interrupting that flow could be a source of
distraction at least, and frustration at worse.
 
I have to following problem: Imagine some kind of data the users of my
application got to see. Based on this data they decide if it concerns them
and they want to edit the data or if does not concern them in which case
they should not be allowed to modify the data.
Click to expand...

So they will decide for themselves whether they should be allowed to edit
data?

If editing data is a common/frequent thing I would present the data in an
edit form and put a submit button (named Update) at the bottom that posts
back the possibly changed data. To top it off you could have the Update
button disabled until anything is changed.

If it were a read-many-write-incidently type of system I would separate the
two (viewing and updating) all the way and not offer any means of updating
in the viewing section which can then be optimized for viewing without
distraction. You would for instance rather have plain text describing some
characteristic than an option button list with all values that do not apply
to the item viewed and only the one that does apply selected. You would have
a separate set of update forms then. You could still present a discrete
button in the view to those with sufficient access rights to enable them to
jump to the update section containing the data they are viewing.

Martin.
 
Back
Top