It seems that Ctrl-N in Mozilla opens a new empty browser window.
That's fine, I don't need to do anything about it.
But Ctrl-N in IE appears to clone the current window. Is there a way
to intercept the key so that I can do stuff on the server side to make
the new window behave correctly?
(We have a JSP-based webapp which stores state in the session. Now if
two windows access (and modify!) the same session, then madness will
result. So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then they
have two instances of the application that they can interact with
independently.)
Kai
13  9380 
"Kai Grossjohann" <ka*@emptydomain.de> wrote in message
news:87************@emptyhost.emptydomain.de... It seems that Ctrl-N in Mozilla opens a new empty browser
window. That's fine, I don't need to do anything about it.
But Ctrl-N in IE appears to clone the current window. Is
there a way to intercept the key so that I can do stuff on
the server side to make the new window behave correctly?
(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result.
Does it? Perhaps you should be looking at creating more robust session
interaction code.
So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then
they have two instances of the application that they can interact
with independently.)
Client-side (JavaScript) fixes are not going to help (especially if they
involve intercepting keyboard events) as it is just not that reliable.
So the degree to which it is important to notify the server of the
creation of a new window is also the degree to which it is inappropriate
to attempt to use client side scripting for the task. Fix the
server-side code so that it can cope with multiple window interacting
with the same session.
Richard.
"Kai Grossjohann" <ka*@emptydomain.de> schrieb im Newsbeitrag
news:87************@emptyhost.emptydomain.de... It seems that Ctrl-N in Mozilla opens a new empty browser window.
That's fine, I don't need to do anything about it.
But Ctrl-N in IE appears to clone the current window. Is there a way
to intercept the key so that I can do stuff on the server side to make
the new window behave correctly?
(We have a JSP-based webapp which stores state in the session. Now if
two windows access (and modify!) the same session, then madness will
result. So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then they
have two instances of the application that they can interact with
independently.)
It seems that IE opens the new window without a name even if the original
one has a name. So you could try something like (I am sorry I don't know the
JSP syntax):
- Create the session in an entry page before starting the application
- Start the app in a new window with window.open() and use the session id as
window name
- Put a script in the head some like
if(top.name != "[input session id here]") {
location.replace("[input page name here]?sessionclone=yes");
}
- At the server side you check for the sessionclone getvariable.
HTH
Markus
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes: "Kai Grossjohann" <ka*@emptydomain.de> wrote in message
news:87************@emptyhost.emptydomain.de...
(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result.
Does it? Perhaps you should be looking at creating more robust session
interaction code.
It seems I was unable to think of a better design. The webapp has
queries and result lists. It provides functionality for showing more
than one query and more than one result list in the same session; an
identifier for the query/result list is stored in the URL.
Lets's say I'm viewing ResultList.jsp?id=foo, which gives the id of
the result list. Now I click on a column heading which means to sort
the result list by that column. Then the webapp modifies the session
attribute to indicate "sorted by column X", then reinvokes
ResultList.jsp?id=foo. That JSP looks in the session for the result
list and visualizes it.
This two-step approach is useful because it means that the reload
button will always work: the URL shown in in the location bar of the
window just reads the current state from the session, all user actions
first modify the session then redirect back to the same
session-display URL.
Now hitting Ctrl-N means that two windows will show the same session
attribute (identified by id=foo). Now the user sorts on a column in
one window and hits reload in another window, and then the other
window will display the sort order set by the user for the first
window.
How to solve this problem?
So I'd like to clone the server-side session, as well. That
way, users can do what they expect -- they hit Ctrl-N and then
they have two instances of the application that they can interact
with independently.)
Client-side (JavaScript) fixes are not going to help (especially if they
involve intercepting keyboard events) as it is just not that reliable.
Actually, I wanted to intercept the creation of a new window, not the
user hitting Ctrl-N... Some browsers might use different kbd
shortcuts.
So the degree to which it is important to notify the server of the
creation of a new window is also the degree to which it is inappropriate
to attempt to use client side scripting for the task. Fix the
server-side code so that it can cope with multiple window interacting
with the same session.
If it was that easy...
Kai
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> writes: It seems that IE opens the new window without a name even if the original
one has a name. So you could try something like (I am sorry I don't know the
JSP syntax):
- Create the session in an entry page before starting the application
- Start the app in a new window with window.open() and use the session id as
window name
- Put a script in the head some like
if(top.name != "[input session id here]") {
location.replace("[input page name here]?sessionclone=yes");
}
- At the server side you check for the sessionclone getvariable.
Beautiful!
Kai
Kai Grossjohann wrote on 12 Dec 2003 at Fri, 12 Dec 2003 11:11:49
GMT: It seems that Ctrl-N in Mozilla opens a new empty browser
window. That's fine, I don't need to do anything about it.
But Ctrl-N in IE appears to clone the current window. Is there
a way to intercept the key so that I can do stuff on the server
side to make the new window behave correctly?
(We have a JSP-based webapp which stores state in the session.
Now if two windows access (and modify!) the same session, then
madness will result. So I'd like to clone the server-side
session, as well. That way, users can do what they expect --
they hit Ctrl-N and then they have two instances of the
application that they can interact with independently.)
What good will that do? They can still do it from the menu bar. Opera
users can duplicate a page from the menu bar or using the default
Ctrl+Shift+N keystroke[1] so your block won't work. What if I opened
a link in another window, then went back to the page in the original
window? What if I use another browser that uses Ctrl+N for a
completely different function and you block it?
I think the only reliable solution is to add concurrency to your
pages.
Mike
[1] I say default because I could change it to anything I want.
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Michael Winter <M.******@blueyonder.co.invalid> writes: What good will that do? They can still do it from the menu bar.
I'm sorry. Of course, I wanted to intercept the *operation*, not the
*keystroke*. But there's nothing "of course" about it for you as a
reader.
Kai
"Kai Grossjohann" <ka*@emptydomain.de> wrote in message
news:87************@emptyhost.emptydomain.de...
<snip> It seems I was unable to think of a better design. The webapp
has queries and result lists. It provides functionality for
showing more than one query and more than one result list in
the same session; an identifier for the query/result list is
stored in the URL.
Lets's say I'm viewing ResultList.jsp?id=foo, which gives the
id of the result list. Now I click on a column heading which
means to sort the result list by that column. Then the webapp
modifies the session attribute to indicate "sorted by column X",
then reinvokes ResultList.jsp?id=foo. That JSP looks in the
session for the result list and visualizes it.
This two-step approach is useful because it means that the
reload button will always work: the URL shown in in the
location bar of the window just reads the current state
from the session, all user actions first modify the session
then redirect back to the same session-display URL.
Now hitting Ctrl-N means that two windows will show the same
session attribute (identified by id=foo). Now the user sorts
on a column in one window and hits reload in another window,
and then the other window will display the sort order set by
the user for the first window.
How to solve this problem?
As I read it the problem stems from the decision to sort the data stored
in the session, and I am unsure why you are doing this at all. I would
have been inclined to store the data in the session in a form that
facilitated its efficient storage and ordered retrieval, but have the
script that generated the HTML output make the decision about what order
to present the information in. Storing/sending the sorting criteria and
direction in the URL with the id of the results list, i.e.:-
ResultList.jsp?id=foo&sortCol=3&sordDirection=up
As a result refreshing would work because the user would get the date
back in the form they last specified in the URL. The back button would
work, as they would get the date in the form specified in the previous
URL. And it would not matter if the user had half a dozen browsers
simultaneously accessing id=foo as they would all be getting the data
sorted in the way they asked for individually.
In addition, with appropriate caching and expires headers, the server
load could be reduced because any response to -
ResultList.jsp?id=foo&sortCol=3&sordDirection=up - would have identical
content to other request for the same URL so the browser could (and so
should) be able to re-use a cached page if it had one. While as you have
it now the server must re-sort the data in the session on each and every
occasion that the user requests a change in the order of presentation,
even if that is just a return to the order in which they previously
requested it.
<snip>Actually, I wanted to intercept the creation of a new window,
not the user hitting Ctrl-N... Some browsers might use
different kbd shortcuts.
There is no window/tab opening/creation/cloning/etc event to intercept.
While keyboard events can be responded to, but as you say that would
depend on a lot of invalid assumptions about the meaning of key
sequences and also be subject to all of the unreliability of client-side
scripting in general and mechanisms aimed at preventing the antisocial
use of scripts to destroy normal browser UI features (no right click and
so on). There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.
Richard.
"Richard Cornford" <ri*****@litotes.demon.co.uk> schrieb im Newsbeitrag
news:br**********@sparta.btinternet.com...
<snip> There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.
My proposal is not a solution for the actual problem. It is just a
workaround for some cases:
Case 1: UA is not Internet Explorer. There is no problem, as a new window
will be empty.
Case 2: UA is Internet Explorer, and Javascript turned on. Here the solution
I proposed works as it creates a new session. Note that I did not discuss
the question if that is desirable or not. There are types of applications
where this is undoubtedly not desirable, for example a shopping cart. If you
create a new session there, you will confuse the user by giving two
different shopping carts which is definitely not desirable. But this is not
the type of application that the OP was related to.
Case 3: UA is Internet Explorer, and Javascript turned off. Here you have 2
possibilities:
a) You open the applicaton with window.open() as I proposed to prevent
non-Javascript users from opening it at all. This is ok if Javascript is
crucial in other parts of your application, too - for example select boxes
with Javascript-created dynamic option field sets or whatever. Of course you
have to tell your users to activate Javascript, and some will be angry about
you.
b) You provide a way to open the application without Javascript (<a
href="myapp.jsp" target="[session id]"> will do the same as the
window.open() I proposed). So a very small part of users will have the
cloned session problem, as I think most people who have installed Internet
Explorer don't care about disabling Javascript.
You could even hide the whole thing from non-IE browsers by using the 3b)
solution by doing a serverside browser sniff and write the target attribute
only to IE browsers. So all popup blocker and broken back button issues will
not occur on non-IE browsers.
Maybe my proposal introduces more problems that I don't see, then I am very
interested to know about them.
--
Markus
"Richard Cornford" <ri*****@litotes.demon.co.uk> wrote in message news:<br**********@sparta.btinternet.com>... "Kai Grossjohann" <ka*@emptydomain.de> wrote in message
news:87************@emptyhost.emptydomain.de...
<snip>
This two-step approach is useful because it means that the
reload button will always work: the URL shown in in the
location bar of the window just reads the current state
from the session, all user actions first modify the session
then redirect back to the same session-display URL.
Now hitting Ctrl-N means that two windows will show the same
session attribute (identified by id=foo). Now the user sorts
on a column in one window and hits reload in another window,
and then the other window will display the sort order set by
the user for the first window.
How to solve this problem?
As I read it the problem stems from the decision to sort the data stored
in the session, and I am unsure why you are doing this at all. I would
have been inclined to store the data in the session in a form that
facilitated its efficient storage and ordered retrieval, but have the
script that generated the HTML output make the decision about what order
to present the information in. Storing/sending the sorting criteria and
direction in the URL with the id of the results list, i.e.:-
ResultList.jsp?id=foo&sortCol=3&sordDirection=up
As a result refreshing would work because the user would get the date
back in the form they last specified in the URL. The back button would
work, as they would get the date in the form specified in the previous
URL. And it would not matter if the user had half a dozen browsers
simultaneously accessing id=foo as they would all be getting the data
sorted in the way they asked for individually.
(Aside: the data as stored in the session is not necessarily sorted,
we just store the sorting criteria in the session, along with the data
itself.)
One reason for not putting this information (which way is the data
sorted) into the URL is that it causes inconsistencies with frames.
Our application uses frames heavily. Now if one subframe changes its
URL, and people hit the web browser's reload button, then madness will
result.
You might say that the madness results from using frames in the first
place. I agree. However, "thou shalt make that it looketh like this
Windows app over here", management decreed. And that Windows app has
resizable, err, I think they're called panes in the Windows world.
Rather than trying to emulate drag and drop in JavaScript, I opted for
using frames.
Another reason is that users might enter a new query into the query
form. Then our app stores a new result list under the old id. I
think you can quickly see how cloning a window, typing a new query in
one window, then hitting reload in the other one, will lead to
problems ;-) There are reports from real-world users who have result
lists containing thousands of items, so storing the result lists
themselves in the URL is not practical.
In addition, with appropriate caching and expires headers, the server
load could be reduced because any response to -
ResultList.jsp?id=foo&sortCol=3&sordDirection=up - would have identical
content to other request for the same URL so the browser could (and so
should) be able to re-use a cached page if it had one. While as you have
it now the server must re-sort the data in the session on each and every
occasion that the user requests a change in the order of presentation,
even if that is just a return to the order in which they previously
requested it.
Well, surely storing the sort order information in the session, rather
than the URL, does not prevent us from using clever caching, if that
proves necessary.
<snip>Actually, I wanted to intercept the creation of a new window,
not the user hitting Ctrl-N... Some browsers might use
different kbd shortcuts.
There is no window/tab opening/creation/cloning/etc event to intercept.
While keyboard events can be responded to, but as you say that would
depend on a lot of invalid assumptions about the meaning of key
sequences and also be subject to all of the unreliability of client-side
scripting in general and mechanisms aimed at preventing the antisocial
use of scripts to destroy normal browser UI features (no right click and
so on). There is no client-side solution and Markus Ernst's proposal
would introduce more problems than it could hope to solve while still
not suitably addressing your window cloning problem, no matter how
"Beautiful" it may seem at first.
Can you give examples of the problems that might result, or is it just
a general gut feeling? I share the general gut feeling, but then
there are these nasty requirements on what I have to do...
Kai
"Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in message
news:3f***********************@news.easynet.ch...
<snip> My proposal is not a solution for the actual problem.
I could quote that line in this response and say nothing more on the
subject. Indeed, properly attributed, that line is good enough for a
comic signature.
It is just a workaround for some cases:
Case 1: UA is not Internet Explorer. There is no problem, as
a new window will be empty.
That pre-supposes that the Ctrl-n behaviour is unique to IE browsers.
The OP only suggests that Mozilla does not follow IE, but given 20 odd
Gecko implementations with diverse Uis I doubt that Mozilla's behaviour
is even consistent among Gecko browsers. There is certainly no guarantee
that IE is the only browser that can open a new window showing the
current page, in fact browsers often actively re-produce the behaviour
of IE (especially if designed to run on the Windows OS).
But while the browser may not be IE, and may not clone the current page
into a new window, that browser is still to be exposed to the code and
so the call to window.open. Not all browsers (including pocket IE) can
open new windows, many non-IE browsers include settings that restrict
the opening of new windows and many browsers are used in conjunction
with pop-up blocking software of one type or another. And, of course,
any of those non-IE browsers may have JavaScript disabled or just not
implemented.
Case 2: UA is Internet Explorer, and Javascript turned on. Here
the solution I proposed works as it creates a new session.
Even on (desktop) IE the call to window.open may not result in a new
window and can even result in the navigation of the current (nameless)
window to the URL provided as a parameter to the window.open call. (The
action of various types of pop-up blocker)
<snip>Case 3: UA is Internet Explorer, and Javascript turned off.
Here you have 2 possibilities:
a) You open the applicaton with window.open() as I proposed
to prevent non-Javascript users from opening it at all.
Along with the users of JavaScript incapable browsers, other browsers
with JavaScript disabled, browsers that cannot open new windows and a
proportion of browsers (including JavaScript enabled IE) operating on
conjunction with pop-up blockers.
As JavaScript incapable/disabled browsers may include browsers designed
(or configured) for use by various disabled groups there may even be
legal implications of this action if it is done in a commercial context
under some jurisdictions.
This is ok if Javascript is crucial in other parts of your
application, too -
This is the "bad design justifies worse design" argument again. There
are more web sites and applications that are JavaScript dependent than
there are web sites and applications that *need* to be JavaScript
dependent, by a very large margin. JavaScript dependence more often than
not is a direct result of inadequacies in the developer.
for example select boxes with Javascript-created dynamic
option field sets or whatever.
If you mean the case where the content of a second(+) select box is
populated based on the selection in a first then there are 4 patterns of
authoring such a system that do not create a dependence on JavaScript.
Most of them do not result in a good UI in the absence of JavaScript but
at least the result is always usable. Otherwise, server-side scripting
is completely capable of, and suited to, dynamically generating the
option elements of an HTML select element.
Of course you have to tell your users to activate Javascript,
Some users just will not be able to do that.
and some will be angry about you.
And if you don't needlessly introduce a JavaScript dependence you will
not anger anyone (at least for that reason) and there is no need to
explain, or apologise for, anything.
b) You provide a way to open the application without Javascript
(<a href="myapp.jsp" target="[session id]"> will do the same
as the window.open() I proposed).
That is actually much better than your window.open proposal. It will
still be subject to the action of some pop-up blockers (though you may
reduce that a bit more by explaining that the link will attempt to open
a new window). And it will still result in navigation within the current
(nameless) window on browsers that cannot open new windows and browsers
subject to the actions of content inserting/re-writing proxies
configured to remove TARGET attributes (a standard filter in
Proximatron, for example).
So a very small part of users will have the cloned session problem,
If that is acceptable then there was never really a problem in the first
pace as by and large users will not clone there current browser instance
into a new window so it was only ever a problem that might be
experienced by a small minority.
as I think most people who have installed Internet
Explorer don't care about disabling Javascript.
You could even hide the whole thing from non-IE browsers by
using the 3b) solution by doing a serverside browser sniff
and write the target attribute only to IE browsers.
Server side browser sniffing is about as reliable as using a random
number generator and biasing the results with your favourite
(meaningless) browser usage statistics. You loose all credibility by
even suggesting it.
So all popup blocker and broken back button issues will
not occur on non-IE browsers.
Assuming that you are not proposing excluding non-(desktop)IE browsers,
you are back to assuming that IE's Ctrl-n behaviour is unique to IE (or
at least, given the server-side browser sniffing proposal, unique to
browsers that habitually (or are currently configured to) send UA
headers that are indistinguishable form IE browsers).
Maybe my proposal introduces more problems that I don't see,
then I am very interested to know about them.
Given a combination of an HTML UA capable of communicating via HTTP to a
server running any server-side scripting technology you have a system
that can work for 100% of visitors 100% of the time (all other things,
telephone networks, electricity supplies, etc, being equal). So from a
starting point that is as close to completely reliable as anything
involving electrical and mechanical systems can be it is the design
decisions of humans that undermine that reliability.
Returning to the dependent select element example above, it is fairly
common for there to be a requirement for a users selection at an early
stage in a process to define and limit there choices at a later stage.
That could be implemented as a wizard style interface using only HTML
forms and server-side scripts, or it could be implemented with multiple
dependent select elements on one page. The former does not detract from
the intrinsic reliability that the system started with, the latter
could. But in the latter case there is also the decision about how to
implement the dependent select elements, they will need JavaScript in
order to "work" but they do not need to be unusable in the absence of
JavaScript and that design decision is going to significantly impact on
the reliability of the whole system. Rendering it unusable for between
2 and 80% of potential visitors (depending on which JavaScript
unavailability statistics you believe. Obviously that range of figures
merle reflects the fundamental meaninglessness of statistics relating to
browsers in general).
The decision to put the select elements on the same page might be based
on usability, or appearance, or just an ignorance of the consequences,
and the decision to implement it in a JavaScript dependent way might be
based on the relative cost of employing a developer who understands how
to properly employ JavaScript as opposed to one who merle knows how to
write the code but doesn't know how to design the code for the internet.
Then again it might not have been a decision at all, just the
consequence of assigning the task to someone who didn't know any better.
But the consequences are still an otherwise avoidable loss of
reliability on the whole system.
If a client (who is unlikely to be in a position to make informed
decisions about implementations for themselves) was told that a
percentage of their potential visitors (or worse, customers) where now
being turned away for no better reason than the inability, or
unwillingness, of a developer to design their implementation in a way
that does not detract from the intrinsic reliability of the system then
the client would probably want find a better developer. Of course the
developer is in a position to bamboozle the client into believing that
whatever was implemented is as good as it can be, and that its
shortcomings are unavoidable or intrinsic to the system, or just not
significant. Throwing spurious statistics and guesstimates about "normal
user behaviour" about and talking of "target" audiences and such like.
If a site cannot be visited and used by any and all potential visitors
(or customers) then that is directly the result of (bad) design
decisions and could have been avoided.
Richard.
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes: Does it? Perhaps you should be looking at creating more robust session
interaction code.
Could you or somebody post a good reference for learning how to write
server side applications which are robust in the presence of concurrency
and complicated control-flow between pages? I have a fairly complicated
intranet application for which I'm considering a similar solution to
the OP (just disallow new-browser-window)... I know it's the Wrong Thing.
There must be a body of techniques out there for managing state
interactions in the presence of back-button, duplicate sessions, etc,
I just don't know them!
My particular platform is ColdFusion but the language doesn't matter,
it's the techniques that are important. (Yes, I know this isn't a
server-side newsgroup, but it's relevant to the thread topic.)
thanks for any help,
--
Chris Jeris cj****@oinvzer.net Apply (1 6 2 4)(3 7) to domain to reply.
Christopher Jeris <cj****@oinvzer.net> writes: There must be a body of techniques out there for managing state
interactions in the presence of back-button, duplicate sessions, etc,
I just don't know them!
Same here.
One alternative that comes to my mind is to store all state in the
request. That is, put it in hidden fields for the forms, or query
parameters for the links. Then everything that the user does will
include the state, and Bob's your uncle.
That's how Google does it, for example.
My problem is that the state is too large to be stored in a URL. (Too
large means several MB in my case.)
Kai
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes: "Markus Ernst" <derernst@NO#SP#AMgmx.ch> wrote in message
news:3f***********************@news.easynet.ch...
<snip>
This is ok if Javascript is crucial in other parts of your
application, too -
This is the "bad design justifies worse design" argument again.
It needs to look (and feel) like the Windows application that I'm
supposed to be emulating. And that Windows application uses drag and
drop rather extensively, for instance.
If you say it makes no sense to write a webapp that looks and feels
like a Windows application, then I agree. But it is not up to me to
make that decision, I just need to implement it. I already voiced my
opinion, what more can I do?
Do you know the vertical bar on the left of the MS Outlook program?
(It lists "Outlook Shortcuts", "My Shortcuts" and "Other Shortcuts",
and inside each group there is a list of icons pointing to email
folders, for example.) There is a company (javascript.cooldev.com)
selling a JavaScript component that looks just the same, and behaves
quite similar, and after seeing this, management has decided that the
webapp absolutely must have an outlook bar that looks at least as good
as that JavaScript component. So we bought the JavaScript component.
It's completely unusable (you can't scroll the list of items with the
wheel, for instance, and you can't use the keyboard to scroll it, and
you can't even hold down the mouse over the scroll button to
continuously scroll).
Kai This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mike Maxwell |
last post by:
<vent> I see there has been traffic over the years on this gripe, so just
let me vent my frustration, and add another reason why 'exit' (or possibly
exit() or quit() or halt() or some such) should...
|
by: Morten Overgaard |
last post by:
Hi all
Is it possible for a .Net app. to intercept the "open" action on files in a
given directory.
I want to intercept the "open" action and the perhaps direct the client (
the app. which is...
|
by: Imran |
last post by:
Hi,
Please bear with me as I have only 1 weeks .NET experience.
I am using VB.NET to write a stand-alone client application that
connects to a Web service. I successfully send a request for a...
|
by: VitoriaTang |
last post by:
I want to know how to capture the paste message.
I tried to capture the WM_PASTE, but it seems as the
richtextbox doedn't send this message.
But in fact, I can find the textbox will send paste...
|
by: Glen Hong |
last post by:
I have set up a hotkey using RegisterHotKey API function for Ctrl-Tab.
Firstly, I can rap this when Ctrl-Tab is pressed however if I want to
add an addition hotkey how can I distinguish between...
|
by: Jiong Feng |
last post by:
Hi,
I have a ASP.net application, which is in root folder.
I hope my http module to intercept requests like:
http://localhost/abc/def
http://localhost/abc/def/
http://localhost/abc/
where...
|
by: Ben de Vette |
last post by:
Hi,
When a user submits a form I want to return him/her a page, but at the same
time I want to send him/her an exact copy of this page by mail.
Is there a way to intercept the rendered HTML of...
|
by: rpale |
last post by:
We want to create server-side code that will retrieve the user requested
pages, then manipulate the content of those pages just before being sent back
to the user. We tried the following:
...
|
by: RJ45 |
last post by:
Hello,
I am writing a shell in C.
I need to intercept Signals like CTRL+C or CTRL+D
and set to ignore them. This is on Unix, using gcc.
my goal is to avoid users escaping the shell with SIGINT...
|
by: ADN |
last post by:
Hi, I am creating a custom HTTPModule to intercept the request of when
the user is attempting to retrieve a session variable. For instance,
if I set a session variable in my code like so:
...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| |
