I want the same function to be run whether you press Enter or double
click the listbox. It seems really verbose to write both handlers to
both events everytime, even if they both call the same function, or
one calls the other.
Isn't there an event for 'ListBox selection selected' that is
automatically called by ALL the standard GUI ways of doing it? C'mon,
this is C#, we aren't supposed to be programming the GUI. There has
to be such an event, or else most C# GUI code has broken UI.
If there's no sense event, I could make a generic handler for any
ListBox's Enter press, which calls the listbox's DoubeClick event.
How can I invoke such an event? I seem unable to call
Control.RaiseMouseEvent to force DoubleClick to be invoke as needed.
I'm a little lost wondering why this basic GUI functionality is so
difficult in C#.
Zytan
18  4574 
You could extend the list box and invoke your own event in place of the the
events you are interested in.
Jeremy Shovan
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
>I want the same function to be run whether you press Enter or double
click the listbox. It seems really verbose to write both handlers to
both events everytime, even if they both call the same function, or
one calls the other.
Isn't there an event for 'ListBox selection selected' that is
automatically called by ALL the standard GUI ways of doing it? C'mon,
this is C#, we aren't supposed to be programming the GUI. There has
to be such an event, or else most C# GUI code has broken UI.
If there's no sense event, I could make a generic handler for any
ListBox's Enter press, which calls the listbox's DoubeClick event.
How can I invoke such an event? I seem unable to call
Control.RaiseMouseEvent to force DoubleClick to be invoke as needed.
I'm a little lost wondering why this basic GUI functionality is so
difficult in C#.
Zytan
You could extend the list box and create your own delegate to get the
functionality you are looking for.
Jeremy Shovan
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
>I want the same function to be run whether you press Enter or double
click the listbox. It seems really verbose to write both handlers to
both events everytime, even if they both call the same function, or
one calls the other.
Isn't there an event for 'ListBox selection selected' that is
automatically called by ALL the standard GUI ways of doing it? C'mon,
this is C#, we aren't supposed to be programming the GUI. There has
to be such an event, or else most C# GUI code has broken UI.
If there's no sense event, I could make a generic handler for any
ListBox's Enter press, which calls the listbox's DoubeClick event.
How can I invoke such an event? I seem unable to call
Control.RaiseMouseEvent to force DoubleClick to be invoke as needed.
I'm a little lost wondering why this basic GUI functionality is so
difficult in C#.
Zytan
Zytan,
Funny, I don't recall where in the C# spec it says we shouldn't be
coding UI...
It is better this way, to be honest, and most UIs out there are not
broken because of this.
You just have to wire up your class to have both event handlers to route
to the same code. It's not that hard.
If you have a number of listboxes that require this functionality, then
just extend the ListBox class and create a new event which you can hook up
to which fires when either of those events takes place.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Zytan" <zy**********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
>I want the same function to be run whether you press Enter or double
click the listbox. It seems really verbose to write both handlers to
both events everytime, even if they both call the same function, or
one calls the other.
Isn't there an event for 'ListBox selection selected' that is
automatically called by ALL the standard GUI ways of doing it? C'mon,
this is C#, we aren't supposed to be programming the GUI. There has
to be such an event, or else most C# GUI code has broken UI.
If there's no sense event, I could make a generic handler for any
ListBox's Enter press, which calls the listbox's DoubeClick event.
How can I invoke such an event? I seem unable to call
Control.RaiseMouseEvent to force DoubleClick to be invoke as needed.
I'm a little lost wondering why this basic GUI functionality is so
difficult in C#.
Zytan
On Fri, 13 Apr 2007 10:03:52 -0700, Zytan <zy**********@gmail.comwrote:
[...]
I'm a little lost wondering why this basic GUI functionality is so
difficult in C#.
In addition to what Nicholas wrote, I will point out that C# is a language
and is substantially UI-independent. .NET Framework is where your
complaints about lack of GUI support should be directed, even if valid
(which is debatable...it's not a foregone conclusion that what works best
for your ListBox works best for everyone's).
Pete
Funny, I don't recall where in the C# spec it says we shouldn't be
coding UI...
I thought the .NET framework was to wrap the Win32 code to make it
easy to use. For all things that should just happen the same way, the
framework handles, forcing UI standardization. This particular
feature of the ListBox is left out. .NET does an amazing job, i am
just surprised why they forgot this.
It is better this way, to be honest, and most UIs out there are not
broken because of this.
Any ListBox that doesn't invoke the same function on doubleclick on on
enter press is broken. Since .NET doesn't force this issue, there's
bound to be code that isn't programmatically enforcing it.
You just have to wire up your class to have both event handlers to route
to the same code. It's not that hard.
Yes, I know, and that's what I'll do. I was hoping you experts would
know of a more proper way.
If you have a number of listboxes that require this functionality, then
just extend the ListBox class and create a new event which you can hook up
to which fires when either of those events takes place.
And that's the real issue, isn't it? I do have a bunch. So the first
suggestion because extremely verbose, as my OP stated. This
suggestion is rather complicated to solve such a simple issue, don't
you think?
I must be mistaken. The standard UI for ListBoxes must not be that
the same function is called for doubleclick and enter. That's the
only way .NET could not force this. But, even if it's not standard
UI, i bet most of us believe it is. Either way, I'm just really
surprised.
Thanks for your posts,
Zytan
P.S. I've reworked my app to not need double click, so for me, the
problem has been postponed to some future date.
I will point out that C# is a language
and is substantially UI-independent. .NET Framework is where your
complaints about lack of GUI support should be directed
Quite correct. I replied to Nicholas stating .NET instead of C#. It
is not C#'s fault.
even if valid
(which is debatable...it's not a foregone conclusion that what works best
for your ListBox works best for everyone's).
I have yet to find one list box where enter doesn't do the same thing
as double click. Believe me, this isn't just a personal issue. if
it's intuitive for the vast majority of users to expect this, then it
should be standard UI, if it isn't.
I could be completely wrong, but I see no evidence of it, yet.
Zytan
On Fri, 13 Apr 2007 13:01:56 -0700, Zytan <zy**********@gmail.comwrote:
[...]
I have yet to find one list box where enter doesn't do the same thing
as double click. Believe me, this isn't just a personal issue. if
it's intuitive for the vast majority of users to expect this, then it
should be standard UI, if it isn't.
If the intent was for double-click to ALWAYS do the same thing as pushing
the Enter key, then there would be no point in having two different events
in the first place.
As an example of where you might want two different actions, consider the
list box where double-clicking selects and executes (same as selecting and
clicking an "Okay" button or something), and hitting the "Enter" key puts
you in some sort of "rename the item" mode. That's a perfectly legitimate
discrimination between the two actions, and is in fact one I've seen and
believe to not be all that rare.
The fact that most situations do use the two actions to mean the same
thing does not mean that all situations will have that characteristic.
And given that, it would be unreasonable of the UI API to arbitrarily
restrict making the distinction.
Also, keep in mind that .NET is designed to wrap Win32, not superseded
it. If Win32 allows it, then .NET should allow it. There's no reason for
..NET to make additional design restrictions on applications, and in fact
if it did it would just encourage people used to Win32 programming to
avoid .NET. Given that in the long run it's good for Microsoft (and
probably for Windows users generally) for Windows software to migrate to
..NET, the last thing Microsoft should want to do is add new restrictions
that would discourage that migration.
Pete
Zytan,
I've reordered the items here to make it easier to follow my points.
See inline:
I must be mistaken. The standard UI for ListBoxes must not be that
the same function is called for doubleclick and enter. That's the
only way .NET could not force this. But, even if it's not standard
UI, i bet most of us believe it is. Either way, I'm just really
surprised.
Even though it might be commonly accepted that the functionality is this
way, the fact exists that on the Win32 level, you can override this
functionality to make it do what you want. To put it in .NET and not offer
the same level of customization would be remiss.
There is no standard, but rather, guidelines, and there is no obligation
to enforce them with the voracity that you would a standard.
It is easier to leave these as separate events, and then have you
composite them into what you need, as opposed to forcing it into a single
event, and then limiting the opportunity for customization when someone else
needs it. In programming, it is always easier to put together smaller
operations into larger ones, than to take larger operations apart.
And that's the real issue, isn't it? I do have a bunch. So the first
suggestion because extremely verbose, as my OP stated. This
suggestion is rather complicated to solve such a simple issue, don't
you think?
No, it's not complicated. You are talking about a very small amount of
code, if at most to create the ListBox that derives from the ListBox,
override the OnDoubleClick and OnKeyPress methods, and exposes the new
event. Then, all you have to do is replace the instances of the regular
listbox, with yours.
Any ListBox that doesn't invoke the same function on doubleclick on on
enter press is broken. Since .NET doesn't force this issue, there's
bound to be code that isn't programmatically enforcing it.
Because you are mistaken (and yes, I know you were being facetious, but
you are mistaken in this case, with all due respect), you can't say that it
is broken. The guideline is not being adhered to, in the name of easier
customization.
Yes, I know, and that's what I'll do. I was hoping you experts would
know of a more proper way.
Creating a subclass of the ListBox is the proper way. You could create
an implementation of IMessageFilter and then based on the handle of the
window that the message is going to, determine the type of the window, and
if it is an enter key press, you can change the type of the message going to
the window (for only listbox windows) to be that of a double click. Instead
of sending the message for a double click, you might want to swallow the
message and call SendInput to send the mouseclicks. This way, you get the
full double click operation (mouse button down, up, down up, double click)
instead of just the one.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
Even though it might be commonly accepted that the functionality is this
way, the fact exists that on the Win32 level, you can override this
functionality to make it do what you want. To put it in .NET and not offer
the same level of customization would be remiss.
You can override pretty much anything in Win32, and lost of people do,
and they break good UI in the process sometimes (even if it is just
the appearance, not the functionality). I see it all the time.
To me, a listbox that does something different on enter press or
double click is like a button that does something different on enter
press or click. I am astonished that this isn't so deep into UI
standards that it is just the thing that happens, and if you wish to
change it (thus breaking intuitive UI), you will have some work ahead
of you, just as you would if you wanted to make enter press / click
for a button do two different things.
I'd love to see one example of good UI where listboxes do two
different actions. If I seen just one, it may influence my decision,
and I know that maybe I'm just missing something, but from my current
perspective, i am having difficulty imagining what.
Regarding all your points, if this isn't standard UI, then yes, .NET
is doing the Right Thing. And yes, it's easier to build up, than
break apart. Agreed on all accounts.
No, it's not complicated. You are talking about a very small amount of
code, if at most to create the ListBox that derives from the ListBox,
override the OnDoubleClick and OnKeyPress methods, and exposes the new
event. Then, all you have to do is replace the instances of the regular
listbox, with yours.
Ok, great! If I run into this again, I'll try this.
Because you are mistaken (and yes, I know you were being facetious, but
you are mistaken in this case, with all due respect), you can't say that it
is broken. The guideline is not being adhered to, in the name of easier
customization.
It may not be a broken standard, if the standard doesn't state it
should perform the same action. But, if millions of people expected
it, it's a de facto standard. In that sense, their code would contain
broken intuitive UI (not standard UI). I imagine there's a lot of it
out there. Me being a keyboard junkie usually finds them before
anyone else does, and why I'm anal about this.
Creating a subclass of the ListBox is the proper way. You could create
an implementation of IMessageFilter and then based on the handle of the
window that the message is going to, determine the type of the window, and
if it is an enter key press, you can change the type of the message going to
the window (for only listbox windows) to be that of a double click. Instead
of sending the message for a double click, you might want to swallow the
message and call SendInput to send the mouseclicks. This way, you get the
full double click operation (mouse button down, up, down up, double click)
instead of just the one.
I don't ever recommend faking mouse actions by mimicing the action
mouse events, since it leads you into situations that you may not
expect. Say you have one button that does the same action as another,
so you mimic the events of the other. After doing so, you'll find the
focus changed improperly. But, I understand the desire to mimic the
full double click (after a single click event). However, for a
listbox, the selection should be the same as a single click. Thus,
these concerns are taken care of (you already got your single click -
you don't get it again when you press enter). (and of course, my same
argument applies, using the arrow keys to change selection should
cause the same events as single clicking, and i think that it does).
Zytan
If the intent was for double-click to ALWAYS do the same thing as pushing
the Enter key, then there would be no point in having two different events
in the first place.
Yes, exactly, and we could respond to just one event. All the UI
issues are handled for us. Just like we don't have to worry about if
the user press Enter or clicked on a button. We just get
'button_click' invoked.
As an example of where you might want two different actions, consider the
list box where double-clicking selects and executes (same as selecting and
clicking an "Okay" button or something), and hitting the "Enter" key puts
you in some sort of "rename the item" mode. That's a perfectly legitimate
discrimination between the two actions, and is in fact one I've seen and
believe to not be all that rare.
So, Enter = rename. I can see this existing in inhouse apps, but that
is just not standard or intuitive UI. It's only intuitive for someone
trained on that app. Enter means execute. F2 is rename. Even VS
gets that wrong sometimes, but since when have the VS team ever done
UI properly (and they readily admit so), so they aren't a great team
to look up to for that stuff.
Thanks for the example.
The fact that most situations do use the two actions to mean the same
thing does not mean that all situations will have that characteristic.
And given that, it would be unreasonable of the UI API to arbitrarily
restrict making the distinction.
I think the only apps that don't do it are made by people who don't
know UI very well. I think it's a de facto standard. All it takes is
a few beta tests to see what happens, and what people expect. Of
course, for a team of people who have years experience with non-
standard UI, they will come to expect it that way. Just like Mac vs.
Windows. Each is right, as long as you are used to it.
I just can't believe people don't think of Enter as 'execute'.
But then again, some inhouse apps have to change what Enter means,
since people think of Excel when they are filling out dialogs. So,
they're must be a bunch of inhouse apps with broken UI, so .NET didn't
want to make it hard for them. (Of course, the UI isn't broken to
THEM).
Also, keep in mind that .NET is designed to wrap Win32, not superseded
it. If Win32 allows it, then .NET should allow it. There's no reason for
.NET to make additional design restrictions on applications, and in fact
if it did it would just encourage people used to Win32 programming to
avoid .NET. Given that in the long run it's good for Microsoft (and
probably for Windows users generally) for Windows software to migrate to
.NET, the last thing Microsoft should want to do is add new restrictions
that would discourage that migration.
Yes, agreed.
Zytan
On Mon, 16 Apr 2007 11:18:18 -0700, Zytan <zy**********@gmail.comwrote:
[...]
So, Enter = rename. I can see this existing in inhouse apps, but that
is just not standard or intuitive UI. It's only intuitive for someone
trained on that app.
It seems to me that you have started with a preconceived notion of what
you want the UI to do, and have decided that if it doesn't do that, you
will call it "not intuitive".
For the record, the "original"(*) "intuitive user interface" -- the
Macintosh OS -- uses *exactly* the paradigm I mentioned. It's one of the
reasons I brought it up. For example, in Finder when you are looking ata
list of files (which is like a listbox), if you hit the Enter key you are
put into the "rename" mode. If you double-click on an item, it executes
or opens it.
You may successfully argue that the vast majority of Windows applications
don't use this paradigm, but I cannot take seriously any claim that
insists that there is no alternative implementation of a list-based
user-interface that cannot be just as "standard" or "intuitive". I see no
reason for a Windows application to not duplicate this behavior when it's
desirable.
In fact, even in Windows *where* you double-click makes a difference in
the behavior of double-clicking. So technically, Windows has the opposite
behavior: Enter always executes, while double-click often puts you into
renaming mode.
[...]
I think the only apps that don't do it are made by people who don't
know UI very well.
See above. The only way you can continue to support that claim is either
to qualify it and restrict the scope of what you originally wrote, or to
insist that the folks at Apple "don't know UI very well". Whatever else
you might think about them, I really don't think that saying that they
"don't know UI very well" is going to get you very far in any debate. :)
I think it's a de facto standard. All it takes is
a few beta tests to see what happens, and what people expect. Of
course, for a team of people who have years experience with non-
standard UI, they will come to expect it that way. Just like Mac vs.
Windows. Each is right, as long as you are used to it.
Well, I also think that's a stretch. In both Mac and Windows operating
systems, there are elements to the user interface that are NOT right.
They both have room for improvement. But I also disagree that defining
behavior to this kind of precision in even a single operating system is
necessary. It is certainly important to have some broad consistencies,
but each application may have different needs. If there's a reason for
pushing the Enter key to do something different than double-clicking on an
item, why should the operating system or the .NET Framework artificially
prevent that?
I just can't believe people don't think of Enter as 'execute'.
People have an amazing ability to think of Enter as not just "execute" but
other commands as well, depending on context. Humans are very good at
dealing with context-sensitive scenarios.
In any case, whatever conclusions you may arrive in this discussion,
you've already lost the battle to consolidate double-clicking and pushing
the Enter key. It is the way it is, and whether you think it's a good
idea or not, it's going to stay that way. I'm sorry that we haven't been
able to convince you that it's okay that way, since that may mean that you
continue to be irritated by this behavior in the future. But you should
at least get used to the idea. :)
Fortunately, it is pretty trivial for you to override the default
behavior, and do so in an easily reused way. So the actual issue of code
development is very minor. If you think that double-click and Enter
should always be the same thing, then in your programs they always can be,
and without you having to write the code more than once. Be thankful
you're using OOP. :)
Pete
(*) Yes, I know "GUI" existed before the Mac OS.
It seems to me that you have started with a preconceived notion of what
you want the UI to do, and have decided that if it doesn't do that, you
will call it "not intuitive".
No, I am speaking from using a multitude of Windows programs. After
having used many of those, things become intuitive. This may differ
from other platforms, such as mac, or even inhouse apps which change
'standard' Windows UI, like I was saying, by making Enter NOT click
the default button, but act as a Tab, for those people who think
everything works like Excel.
For the record, the "original"(*) "intuitive user interface" -- the
Macintosh OS -- uses *exactly* the paradigm I mentioned. It's one of the
reasons I brought it up. For example, in Finder when you are looking at a
list of files (which is like a listbox), if you hit the Enter key you are
put into the "rename" mode. If you double-click on an item, it executes
or opens it.
Wait a second, the example you mentioned earlier was from Mac? Please
keep the discussion to Windows. Mac has an entirely different UI and
things that intuitive on it are not so on Windows, and vice versa.
There's no one standard among all systems. I was speaking about
within Windows.
You may successfully argue that the vast majority of Windows applications
don't use this paradigm, but I cannot take seriously any claim that
insists that there is no alternative implementation of a list-based
user-interface that cannot be just as "standard" or "intuitive". I see no
reason for a Windows application to not duplicate this behavior when it's
desirable.
If it can be successfully argues that most Windows apps have the
listbox enter / double click = one and the same result, then that
becomes the defacto standard, and by definition, is intuitive. It's
too late, everyone thinks it works this way. That's why people
complain so much when the UI changes from one Windows version to
another, they are used to it, and find it intuitive, and think the new
one isn't intuitive.
In fact, even in Windows *where* you double-click makes a difference in
the behavior of double-clicking. So technically, Windows has the opposite
behavior: Enter always executes, while double-click often puts you into
renaming mode.
No, double click is almost always execute. It's used so much that
most novices think you have to double click everything to make
something happen, including URLs, buy buttons, etc. Double click =
make something happen. If that doesn't show that it's intuitive, I
don't know what does.
I think the only apps that don't do it are made by people who don't
know UI very well.
See above. The only way you can continue to support that claim is either
to qualify it and restrict the scope of what you originally wrote, or to
insist that the folks at Apple "don't know UI very well". Whatever else
you might think about them, I really don't think that saying that they
"don't know UI very well" is going to get you very far in any debate. :)
Apple knows UI very well. As does Microsoft. I am speaking about
Windows UI.
Please see above re: explanation of how intuitiveness is restricted to
a single userbase of people for a single system. Almost everyone
using Windows will think Apple OS UI sucks, and vice versa, because
they are used to their own. It doesn't mean either is wrong. Both
are decent (although I'm sure each has its strengths and weaknesses).
Well, I also think that's a stretch. In both Mac and Windows operating
systems, there are elements to the user interface that are NOT right.
They both have room for improvement.
100% agree.
But I also disagree that defining
behavior to this kind of precision in even a single operating system is
necessary.
To be clear, I am ONLY defining to a single OS. I would never say OS
X should be like this.
To be further clear, I am only defining it to Windows BECAUSE almost
every program in existance for Windows follows it. The 'standardness'
or 'intuitiveness' just natural follows. It's practically defined by
it. Even if the UI is wrong, it's still known by millions, and
therefore you should use it, even if you have a better solution. Like
the VS guys who think it's cool to auto highlight text fields, which
is wrong UI, and I come along and select it all myself, starting from
the right side (where the space is to click and drag the mouse), and
due to their 'improvement', my standard UI task is undone: the result
is that I select nothing, the exact opposite of what I expected, and
what should happen if they has just left the thing alone (it happens
because after they auto-select all, they put the cursor to the far
right!)
It is certainly important to have some broad consistencies,
but each application may have different needs. If there's a reason for
pushing the Enter key to do something different than double-clicking on an
item, why should the operating system or the .NET Framework artificially
prevent that?
It shouldn't, if there's a reason for it to be different. I didn't
think there was any reason, other than purposely breaking intuitive
(to Windows) UI to make your home-brew / inhouse app do something
differently. And I thought this was so easy to do in Win32 or .NET
that it's all ok.
I just can't believe people don't think of Enter as 'execute'.
People have an amazing ability to think of Enter as not just "execute" but
other commands as well, depending on context. Humans are very good at
dealing with context-sensitive scenarios.
Yes, I expect Enter in Excel to be different. So, I agree. But, not
for a standard Listbox, or button, or any other of the standard UI.
In any case, whatever conclusions you may arrive in this discussion,
you've already lost the battle to consolidate double-clicking and pushing
the Enter key. It is the way it is, and whether you think it's a good
idea or not, it's going to stay that way. I'm sorry that we haven't been
able to convince you that it's okay that way, since that may mean that you
continue to be irritated by this behavior in the future. But you should
at least get used to the idea. :)
I think we're mostly on the same page, now that I cleared up from
which direction i'm coming from. Perhaps I underestimate just how
many people make these inhouse apps that operate differently.
Microsoft spends a lot of time making things easy to use, and
standardizing the UI is a good thing. I was just surprised they
didn't take this step. I obviously don't realize just how many apps
use enter to mean something other than execute. It's astonishing.
Fortunately, it is pretty trivial for you to override the default
behavior, and do so in an easily reused way. So the actual issue of code
development is very minor. If you think that double-click and Enter
should always be the same thing, then in your programs they always can be,
and without you having to write the code more than once. Be thankful
you're using OOP. :)
Yes, well, that's the great thing about today, I agree :)
Thanks for your reply,
Zytan
On Mon, 16 Apr 2007 18:52:55 -0700, Zytan <zy**********@gmail.comwrote:
No, I am speaking from using a multitude of Windows programs. After
having used many of those, things become intuitive.
You are not talking about "intuitive" then. "Intuitive" implies that you
can understand it easily with no previous experience. See "intuition":
"direct perception of truth, fact, etc., independent of any reasoning
process; immediate apprehension" or "pure, untaught, noninferential
knowledge" (emphasis on "untaught" and "noninferential")
If previous experience is required, then it is NOT "intuitive". In fact,
that would be the exact *opposite* of "intuitive".
Wait a second, the example you mentioned earlier was from Mac? Please
keep the discussion to Windows. Mac has an entirely different UI and
things that intuitive on it are not so on Windows, and vice versa.
There's no one standard among all systems. I was speaking about
within Windows.
See above. What is intuitive on one OS is intuitive on the other. If
something only becomes familiar after experience with it, then it is NOT
intuitive.
[...]
No, double click is almost always execute. It's used so much that
most novices think you have to double click everything to make
something happen, including URLs, buy buttons, etc. Double click =
make something happen. If that doesn't show that it's intuitive, I
don't know what does.
So what? First of all, you are misusing the word "intuitive". Secondly,
the question of what makes for the correct UI design in most situations in
absolutely no way addresses the question of whether that UI design should
be applied in EVERY situation. You could successfully prove that 99% of
all applications always use double-click and Enter interchangeably and it
would not change the fact that there's no justification for .NET Framework
imposing that standard on applications.
Please see above re: explanation of how intuitiveness is restricted to
a single userbase of people for a single system.
Please see above re: explanation of how "intuitiveness" is necessarily
independent of operating system.
[...]
>It is certainly important to have some broad consistencies,
but each application may have different needs. If there's a reason for
pushing the Enter key to do something different than double-clicking on
an
item, why should the operating system or the .NET Framework artificially
prevent that?
It shouldn't, if there's a reason for it to be different.
Well, there may indeed be reason for it to be different. You can't say
one way or the other in any particular case without inspecting that
particular case. That should be sufficient cause.
[...]
Yes, I expect Enter in Excel to be different. So, I agree. But, not
for a standard Listbox, or button, or any other of the standard UI.
Well, how do you defend Windows Explorer using double-click for something
*other* than "execute"?
I think we're mostly on the same page, now that I cleared up from
which direction i'm coming from. Perhaps I underestimate just how
many people make these inhouse apps that operate differently.
I don't know if we're on the same page. I don't believe that
disconnecting double-click and Enter is appropriate only for "inhouse
apps". I think it makes perfect sense for .NET Framework to retain the
flexibility that the native Windows API offers, rather than forcing a
particular paradigm on the developer and user.
Microsoft spends a lot of time making things easy to use, and
standardizing the UI is a good thing. I was just surprised they
didn't take this step. I obviously don't realize just how many apps
use enter to mean something other than execute. It's astonishing.
I can't tell if you're being sarcastic or not. I don't know, and haven't
made any statement to the effect of, how many applications use Enter "to
mean something other than execute". However, there need not be many to
justify allowing the flexibility of an application doing that.
There doesn't have to be an "astonishing" number of applications that use
Enter as other than "execute" in order to justify the .NET Framework
design.
Pete
You are not talking about "intuitive" then. "Intuitive" implies that you
can understand it easily with no previous experience. See "intuition":
"direct perception of truth, fact, etc., independent of any reasoning
process; immediate apprehension" or "pure, untaught, noninferential
knowledge" (emphasis on "untaught" and "noninferential")
If previous experience is required, then it is NOT "intuitive". In fact,
that would be the exact *opposite* of "intuitive".
Yes, UI should be intuitive, but some things have to be learned, and
those are the differences between mac and windows. Once we learn that
enter = execute, then all other uses of it should be intuitive, as you
said, without needing to learn. So enter on listbox does not execute,
thus is not intuitive. Correct?
It is pedantic to assume absolutely 0 knowledge, you could argue that
forever. Enter is learned. It is not intuitive. It becomes basic
knowledge. Everyone today knows enter = execute. Thus, if you make
enter != execute, you are not being intuitive. If you make enter =
execute, it is intuitive (even though it requires the knowledge of
what enter means).
See above. What is intuitive on one OS is intuitive on the other. If
something only becomes familiar after experience with it, then it is NOT
intuitive.
Note that the reason something is intuitive is because you don't need
experience ON IT. You've learned enter = execute on mac or c-64. Now
you come to Windows. Enter = execute? yes, thus, its intuitive. It
still requires the original perception to have been learned on the
original system. After all, with no experience, nothing is
intuitive. Our brains learned our environment, or a environment, and
it gets used to it. Now, if things happen as we expect, say, a new
car comes about, and the steering wheel turns the same direction to
turn the wheels, and the pedals are in the same order, it is
intuitive. It still requires the initial experience to KNOW what to
expect. A child's brain expects nothing until it learns the
environment.
So what? First of all, you are misusing the word "intuitive".
No, I am most definitely not.
Secondly,
the question of what makes for the correct UI design in most situations in
absolutely no way addresses the question of whether that UI design should
be applied in EVERY situation. You could successfully prove that 99% of
all applications always use double-click and Enter interchangeably and it
would not change the fact that there's no justification for .NET Framework
imposing that standard on applications.
If 1% of the people want the rest of us to learn a new way to use a
common control, they should make a new control. Why re-learn the way
the original works just because somene think their way is better?
Almost always, such thought is shown to be wrong, and even when their
way is better, when you already have almost everyone used to a certain
interface, and thus expecting yours to act in the same manner (i.e.
intuitively even though you have *no experience* using your
interface), then it's a Good Idea to follow suit.
Believe me, I have ideas to improve UI as well.
Please see above re: explanation of how intuitiveness is restricted to
a single userbase of people for a single system.
Please see above re: explanation of how "intuitiveness" is necessarily
independent of operating system.
No, it's not. That's why Windows people hate Mac interface and Mac
people hate the Windows UI. You surely cannot argue that this is the
case. Nor can you argue why it is the case: they both have ZERO
experience using the new system, and through their experiences of
another system (currently not under test), they expect a certain
result from the new one, and when they get a different result, the
result is conclusive: it is not intuitive.
Again I will say: It's intuitive if something you have not used
before reacts as you expect. What you expect derives from past
experiences of OTHER products.
[...]
Yes, I expect Enter in Excel to be different. So, I agree. But, not
for a standard Listbox, or button, or any other of the standard UI.
Well, how do you defend Windows Explorer using double-click for something
*other* than "execute"?
Windows Explorer does execute on double click. By "execute", I don't
mean "begin execution of a program" since the double click may
certainly not be on a program, I just mean "carry out a task" or "DO
something", which I shorten to "execute!". Windows Explorer has
proper UI.
I don't know if we're on the same page. I don't believe that
disconnecting double-click and Enter is appropriate only for "inhouse
apps". I think it makes perfect sense for .NET Framework to retain the
flexibility that the native Windows API offers, rather than forcing a
particular paradigm on the developer and user.
I thought .NET was supposed to make common tasks easier, and since so
many people make these two actions the same, I assumed it would handle
this for me.
Microsoft spends a lot of time making things easy to use, and
standardizing the UI is a good thing. I was just surprised they
didn't take this step. I obviously don't realize just how many apps
use enter to mean something other than execute. It's astonishing.
I can't tell if you're being sarcastic or not. I don't know, and haven't
made any statement to the effect of, how many applications use Enter "to
mean something other than execute". However, there need not be many to
justify allowing the flexibility of an application doing that.
No, no sarcasim at all. I respect MS's efforts. People who make
their own UI judgments, assuming MS doesn't know anything, certainly
do not respect them. I just don't get it. Even if they are right,
and they are better, if people don't expect the new interface, people
will get upset. Why fight it and then lose even when you are right?
There doesn't have to be an "astonishing" number of applications that use
Enter as other than "execute" in order to justify the .NET Framework
design.
I don't believe there are an astonishing number of them, I am
astonished that there are enough that people actually let amateurs
easily create code that does not reflect on what people expect. But
then again, who uses keyboards anymore, so this is likely why no one
cares.
Zytan
On Wed, 18 Apr 2007 13:14:23 -0700, Zytan <zy**********@gmail.comwrote:
[...] If you make enter =
execute, it is intuitive (even though it requires the knowledge of
what enter means).
Well, I disagree. The dictionary agrees with me, but there's nothing I
can do to stop you from using "intuitive" to mean something else. Just
keep in mind that every time you do, you'll have a semantic disconnect
with whomever you're conversing with.
>
>See above. What is intuitive on one OS is intuitive on the other. If
something only becomes familiar after experience with it, then it is NOT
intuitive.
Note that the reason something is intuitive is because you don't need
experience ON IT. You've learned enter = execute on mac or c-64.
Sorry? You've already said other operating systems are irrelevant, and
you said so because of the very fact that no one learned that "enter =
execute on mac" (it doesn't!)
Now you come to Windows. Enter = execute? yes, thus, its intuitive..
It's not intuitive, even by your definition.
It still requires the original perception to have been learned on the
original system. After all, with no experience, nothing is
intuitive.
That's not true. There are a great many behaviors that are innate and
require no real experience. Babies go through a physical development
process that involves learning new things, but also simply developing
physically to the point where their innate intuitive knowledge can be
expressed.
In any case, I don't think it's necessary to even bother making that
point. When it comes to computers, I think it's fine to contrast any
knowledge a person brings by default to the computer, and knowledge that
requires use of the computer to learn. And the distinction between
double-clicking and Enter is definitely "learned" while other activities
on the computer (for example, using a pen and tablet to draw) are
"intuitive".
Our brains learned our environment, or a environment, and
it gets used to it. Now, if things happen as we expect, say, a new
car comes about, and the steering wheel turns the same direction to
turn the wheels, and the pedals are in the same order, it is
intuitive.
Actually, I would say that the steering wheel is a fairly intuitive
interface, while the foot pedals, gear shift and numerous other things are
not. The steering wheel requires very little learning; someone who has
never seen a car before can easily guess which way the wheel should turn
in order to steer the car. The operation of all sorts of other things
definitely needs to be learned, and these things are not intuitive at all.
It still requires the initial experience to KNOW what to
expect. A child's brain expects nothing until it learns the
environment.
You must not have children. Or if you do, you weren't watching very
closely during their early development. A child's brain, even a newborn
infant, already has plenty of built-in expectations. Still, as I say
above I do not believe it's even that important to consider this fact.
The "intuitiveness" of a computer can easily be measured compared to
normal, every-day experiences, without diluting the real meaning of the
word "intuitive".
>So what? First of all, you are misusing the word "intuitive".
No, I am most definitely not.
So you say.
If 1% of the people want the rest of us to learn a new way to use a
common control, they should make a new control.
Why? They should build a whole new list control, from scratch, just
because they want a slightly different input behavior? Are they also
required to ensure that it looks *nothing* like any existing list control,
so as to avoid confusing?
Pardon me, but your point here borders on the bizarre.
Why re-learn the way
the original works just because somene think their way is better?
Like it or not, the computer software industry is *filled* with examples
of different programs providing different user interfaces. In fact, years
of lawsuits are built on the contention that different programs *should*
provide different user interfaces. I disagree with the latter, but I see
no reason that we should swing the pendulum the other way and force a
single user-interface down the throats of every software developer and
every user.
[...]
>Please see above re: explanation of how "intuitiveness" is necessarily
independent of operating system.
No, it's not. That's why Windows people hate Mac interface and Mac
people hate the Windows UI.
No, that's no why "Windows people hate Mac interface and Mac people hate
the Windows UI". That's a silly claim, and ignores the real reason
there's a Mac vs Windows debate: people love their religion. It has
nothing to do with one user interface being different from the other. It
has to do with people having a need to feel that they belong to some
category of people, and that their category of people is better than other
categories of people.
The Mac vs Windows debate is a huge red herring in the context of this
discussion.
You surely cannot argue that this is the case.
It seems that you mistake the meaning of the word "surely" along with
"intuitive". I *am* arguing that "intuitiveness" is necessarily
independent of the operating system, and so obviously I *can* argue that
that's the case.
Just so you know: if you're in a debate and you find yourself claiming
that the other person can't seriously be arguing their side, you've lost
all credibility, along with the debate itself.
[...]
>Well, how do you defend Windows Explorer using double-click for
something *other* than "execute"?
Windows Explorer does execute on double click.
Not all the time it doesn't. For one, you can configure Windows Explorer
to execute on a single click. For another, if you double-click the
filename rather than the icon for the file, you get into the renaming mode.
By "execute", I don't
mean "begin execution of a program" since the double click may
certainly not be on a program, I just mean "carry out a task" or "DO
something", which I shorten to "execute!". Windows Explorer has
proper UI.
Carry out what task? Renaming? Then what's wrong with using Enter to
also mean "execute", that is "renaming"?
I thought .NET was supposed to make common tasks easier, and since so
many people make these two actions the same, I assumed it would handle
this for me.
..NET has many goals. If the only goal was for .NET to make things easier
for you, then why not just make .NET Microsoft's "send us your application
idea and we'll code it for you" program?
The fact is, some of .NET's goals involve making things easier for you.
Other .NET goals involve providing the same functionality that the native
Windows API provides. Unfortunately for you, the latter goal is
overriding the former goal in this case. Oh well. That's life.
Pete
Well, I disagree. The dictionary agrees with me, but there's nothing I
can do to stop you from using "intuitive" to mean something else.
No, I am exactly in line with what the dictionary says. I think
perhaps it is surprising to people that everything they know,
everything they find intuitive, everything they believe to be common
sense, is (almost) all from experience. To say "we expect something
with no experience" could ONLY MEAN no experience on the new task at
hand, because you require past experience to HAVE an expectation to
begin with. That's why babies are (almost) never surprised at
anything, but adults are all the time.
When you move into a new realm, and use your past experience to expect
certain reactions, when the new field performs as expected, it is
intuitive. The expectations of Windows and Mac users show that
intuitive UI is largey a learned thing (with lots of cross over,
obviously).
Regading "enter = execute on Mac", I assumed this was the case, since
it's not, then disregard that wrong example. My point was that other
OS's are irrelevant because we are speaking about Windows. Since
other OS's have their own UI, to which their users find intuitive from
learned experience, then we cannot use that to state whether Windows
UI is proper or not. We must look at only Windows apps to derive that
information.
That's not true. There are a great many behaviors that are innate and
require no real experience.
Yes, that is true, but the extreme, vast majority of everything we
know is from experience. That's what is relevant to expectations of
UI.
When it comes to computers, I think it's fine to contrast any
knowledge a person brings by default to the computer, and knowledge that
requires use of the computer to learn. And the distinction between
double-clicking and Enter is definitely "learned" while other activities
on the computer (for example, using a pen and tablet to draw) are
"intuitive".
I agree. The best UI ever would be one in which a person with no
experience with computers at all could use, perhaps like human speech
on Star Trek. And yes, the whole mouse thing is attempt to approach
that. You seem to be saying when I press Enter and expect something
to happen, on a totally new program I never used before, it is not
intuitive, even though I've never used that program before. What is
this, if it is not intuitiveness.
Actually, I would say that the steering wheel is a fairly intuitive
interface, while the foot pedals, gear shift and numerous other things are
not. The steering wheel requires very little learning; someone who has
never seen a car before can easily guess which way the wheel should turn
in order to steer the car. The operation of all sorts of other things
definitely needs to be learned, and these things are not intuitive at all.
Yes, I agree the steering is more intuitive (but not sure why we
control the top, rather than the bottom, though) than the pedals. I
specifically mentioned the pedals because I realized steering seems
very intuitive, whereas pedals do not.
My point was that when you go to Japan and drive their cars, you'll
find them intuitive because they make use of the pedals in a similar
fashion. If intuitiveness meant no experience EVER then we'd need
another word to describe why Japanese cars are so easy to drive even
though we've never sat in one before.
You must not have children. Or if you do, you weren't watching very
closely during their early development. A child's brain, even a newborn
infant, already has plenty of built-in expectations.
Yes, they do. I agree. But the overwhelming, vast majoryity of
everything they come into contact with and expect from the environment
is from learning. They could learn alien languages if they were
brought up in that environment. They'd learn 0 G physics if brought
up in them. Almost nothing is expected. This is my point. (Almost)
all they find intuitive about the world is learned.
Why? They should build a whole new list control, from scratch, just
because they want a slightly different input behavior? Are they also
required to ensure that it looks *nothing* like any existing list control,
so as to avoid confusing?
Pardon me, but your point here borders on the bizarre.
I just meant that if they want to use a common control in a manner
unlike 99% of the current apps, then maybe they should consider using
another control. Yes, it would have to look different, to avoid
confusion. And since it doesn't exist, they have to program it
themselves. It's way easier to just use the existing one and change
it. That's why it happens. People do it, so .NET lets you do it.
But, none of this makes it intuitive, and it seems like it's here to
stay. Reminds me of the time I read some unix (?) guy made his
programmers make the Enter key act as a tab in his Windows app, since
he was used to it. It can be done. It makes it intuitive for him,
and unix people (?). But, it breaks Windows UI.
No, that's no why "Windows people hate Mac interface and Mac people hate
the Windows UI". That's a silly claim, and ignores the real reason
there's a Mac vs Windows debate: people love their religion. It has
nothing to do with one user interface being different from the other. It
has to do with people having a need to feel that they belong to some
category of people, and that their category of people is better than other
categories of people.
The Mac vs Windows debate is a huge red herring in the context of this
discussion.
Ok, whoa, I was just talking about why one hates the other's
*interface*. I know there's many reasons why each hates each other
completely, and yes, it's all that stuff you said, I agree. I'm just
talking about UI. Like when you try to help a friend use their
computer and it's a different OS. Here's the thought I was trying to
write in better words: http://www.joelonsoftware.com/design/1stDraft/03.html
You surely cannot argue that this is the case.
It seems that you mistake the meaning of the word "surely" along with
"intuitive". I *am* arguing that "intuitiveness" is necessarily
independent of the operating system, and so obviously I *can* argue that
that's the case.
Ok, reword my sentence to:
"You surely cannot provide a legitimate argument that shows this is
false."
Just so you know: if you're in a debate and you find yourself claiming
that the other person can't seriously be arguing their side, you've lost
all credibility, along with the debate itself.
No, it just means the point is so strong, it would be difficult to
raise any legitimate evidence otherwise, but I'm all ears. However,
if the discussion is about a word whose definition is not clear, then
the discussion is merely about definition of a word, and everything
else based on this is meaningless.
Windows Explorer does execute on double click.
Not all the time it doesn't. For one, you can configure Windows Explorer
to execute on a single click. For another, if you double-click the
filename rather than the icon for the file, you get into the renaming mode.
Ok, execute on single click is the user purposely changing the UI to
suit them, but, yes, it's possible, and yes, it'd drive everyone else
crazy trying to use it, since it's not intuitive. The double click
always execute. For a click to get into renaming mode, you need two
single clicks, not one double click. Or did I miss something?
Zytan
On Thu, 19 Apr 2007 14:03:28 -0700, Zytan <zy**********@gmail.comwrote:
[...]
Yes, I agree the steering is more intuitive (but not sure why we
control the top, rather than the bottom, though) than the pedals.
Why control the top? Because if the steering wheel were a wheel on the
ground, then the top is what would move to the same direction in which you
want to direct the car.
In other words, the steering wheel, as a wheel itself, has a direct
analogue to the external, physical world it represents and acts in the
same way. This is truly intuitive behavior; you need not know anything
about cars to understand how the wheel works.
I
specifically mentioned the pedals because I realized steering seems
very intuitive, whereas pedals do not.
You mentioned pedals as an example of intuitive design when at the same
time you realize that the pedals do not seem intuitive? Are you arguing
my side or yours? You seem to be doing a better job defending my point of
view. :p
My point was that when you go to Japan and drive their cars, you'll
find them intuitive because they make use of the pedals in a similar
fashion. If intuitiveness meant no experience EVER then we'd need
another word to describe why Japanese cars are so easy to drive even
though we've never sat in one before.
Well, ignoring for the moment that in Japan they drive on the left side of
the right, whereas I live in a country where they drive on the right (the
US)...
I would not agree that I find Japanese cars any more intuitive than US
cars. They are more *familiar*. But they are no more or less intuitive
than US cars.
>Why? They should build a whole new list control, from scratch, just
because they want a slightly different input behavior? Are they also
required to ensure that it looks *nothing* like any existing list
control, so as to avoid confusing?
Pardon me, but your point here borders on the bizarre.
I just meant that if they want to use a common control in a manner
unlike 99% of the current apps, then maybe they should consider using
another control. Yes, it would have to look different, to avoid
confusion.
So, even if the control behaves basically the same as a list control, but
it requires the use of different meaning for double-clicking and using the
Enter key, you would insist that they must look different?
Sorry, but I just can't get on board that sort of arbitrary assertion.
That'd be like saying that just because the clock in one car uses a
separate button to enter the time-set mode from the hour and minute
buttons, while the clock in another has you hold down the hour or minute
button to enter the time-set mode, there should be a requirement that
those buttons must be designed so as to look different.
One of the worst things you can do in UI design is force something to look
different, just for the sake of looking different. If it walks like a
duck, quacks like a duck, and flies like a duck, then it's pretty silly
IMHO to say you need to dress it up like a chicken just because it lays
white eggs instead of brown.
And since it doesn't exist, they have to program it
themselves.
But the only reason it doesn't exist is that you've insisted it has to
look different, even though it behaves exactly the same as the existing
control.
It's way easier to just use the existing one and change
it. That's why it happens. People do it, so .NET lets you do it.
No one is "just using the existing one and changing it". They aren't
*changing* it, they are extended it. The existing control doesn't do
*anything* with double-click *or* the Enter key. That behavior is
undefined in the basic control, and there's no justification for insisting
that someone should avoid using the basic control just because their use
of the control differs from what you think it should do.
You surely cannot argue that this is the case.
It seems that you mistake the meaning of the word "surely" along with
"intuitive". I *am* arguing that "intuitiveness" is necessarily
independent of the operating system, and so obviously I *can* argue that
that's the case.
Ok, reword my sentence to:
"You surely cannot provide a legitimate argument that shows this is
false."
How is that better? You have prejudged my position by claiming that I
could not possibly come up with a legitimate argument. So by definition,
no matter what I say you will state that it is not legitimate.
>Just so you know: if you're in a debate and you find yourself claiming
that the other person can't seriously be arguing their side, you've lost
all credibility, along with the debate itself.
No, it just means the point is so strong, it would be difficult to
raise any legitimate evidence otherwise, but I'm all ears.
No, you're not. No one who is "all ears" would claim at the outset that
no legitimate argument or evidence exists in the first place.
Ok, execute on single click is the user purposely changing the UI to
suit them, but, yes, it's possible, and yes, it'd drive everyone else
crazy trying to use it, since it's not intuitive. The double click
always execute. For a click to get into renaming mode, you need two
single clicks, not one double click. Or did I miss something?
No, I did. I've been using my Mac more than my Windows computer and have
misplaced my recollection about the Windows Explorer UI. Must've been an
earlier version of Windows that had double-click for renaming.
Still, the fact remains that there are numerous examples of list-like user
interfaces out there, on Windows and not on Windows, and they each have
their own subtle differences in behavior. Claiming that .NET should have
forced a single paradigm on all clients of the list control is arbitrary,
unjustified, and detrimental to the freedoms that application writers
should have in deciding how *their* application will work.
Pete
Why control the top? Because if the steering wheel were a wheel on the
ground, then the top is what would move to the same direction in which you
want to direct the car.
Yes, makes sense.
I
specifically mentioned the pedals because I realized steering seems
very intuitive, whereas pedals do not.
You mentioned pedals as an example of intuitive design when at the same
time you realize that the pedals do not seem intuitive? Are you arguing
my side or yours? You seem to be doing a better job defending my point of
view. :p
I am just trying to find the truth, whether I'm right or wrong.
Pedals are not intuitive for a person who has never seen a car. But,
once learned in the US, and you move to Japan, or to Germany, or
Italy, they are intuitive, even though you've never seen those cars
before! My point: intuitiveness *almost* always relies on past
experiences (in this case, the US cars).
I would not agree that I find Japanese cars any more intuitive than US
cars. They are more *familiar*. But they are no more or less intuitive
than US cars.
Yes, both Japanese and US cars are just as intuitive to drive as each
other (ignoring such things as lanes and driver side), as with German
cars or Italian cars. My point is that once you have driven one, the
rest become intuitive to drive. But only AFTER you have experience
driving at least one.
So, even if the control behaves basically the same as a list control, but
it requires the use of different meaning for double-clicking and using the
Enter key, you would insist that they must look different?
I think if you want to use something that needs to look so much like a
list box, then you should use a list box, and make it act like the 99%
of the listboxes that exist already.
So, I'd say you have a design flaw, if only because people just are
not used to using the control the way you would like it to work.
... there's no justification for insisting
that someone should avoid using the basic control just because their use
of the control differs from what you think it should do.
A good UI performs as you expect, and when 99% of the time a listbox
acts like A, then you should make your listboxes act like A, even if
there is a better way and we would have world peace if we all just
used B, instead.
How is that better? You have prejudged my position by claiming that I
could not possibly come up with a legitimate argument. So by definition,
no matter what I say you will state that it is not legitimate.
Sometimes when something is defined by something else, when you see
it, by definition, you know that it must be the case.
I am still all ears to any evidence otherwise. I didn't mean to imply
that I closed my mind off. Wrong choice of words.
No, you're not. No one who is "all ears" would claim at the outset that
no legitimate argument or evidence exists in the first place.
Sometimes by definition something has to be right because it is
defined that way. Only in those cases would I make such a claim. But
even then, I could be wrong, so I am all ears, always.
My choice of words were bad. What I was looking for was evidence to
the contrary, so I could go from there.
Or did I miss something?
No, I did. I've been using my Mac more than my Windows computer and have
misplaced my recollection about the Windows Explorer UI. Must've been an
earlier version of Windows that had double-click for renaming.
Ok.
Still, the fact remains that there are numerous examples of list-like user
interfaces out there, on Windows and not on Windows, and they each have
their own subtle differences in behavior.
I just never seen these myself. Obviously they exist, since no one
cares that listboxes don't all act the same way.
Zytan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mg |
last post by:
I want to enter characters in a TextBox in a WebForm,
press a Button in the WebForm, and read the characters
that were typed into the TextBox from within the
Button_Click event handler. The main...
|
by: Neo |
last post by:
I think the ENTER key worked this way (in the classic ASP days):
When the end user presss ENTER, IE will submit the page by 'simulating'
a click on the first submit button (or image).
On the...
|
by: Fernando Lopes |
last post by:
Hi.
I one usercontrol, i have a zipcode textbox .
I need to, when user press ENTER, I call a code-behind method, to check this
zipcode on database and, depending the return of this check,...
|
by: George Homorozeanu |
last post by:
Hi,
I have an ASP.Net Page with some control on it (buttons, textboxes,
calender, etc). When I'm changing the text in the textbox I want to run some
code and change the date of the calendar. The...
|
by: Camellia |
last post by:
Hi all,
I'll get straight into it.
When I try to run the code:
.....
while (scanf("%c", &c) == 1)
printf("%c", c);
.....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing...
|
by: Camellia |
last post by:
Hi all,
I'll get straight into it.
When I try to run the code:
.....
while (scanf("%c", &c) == 1)
printf("%c", c);
.....
I input "abcd" follows by an EOF(Ctrl + d) instead of pressing...
|
by: todashah |
last post by:
Hi ! All,
I want to developed simple web page using asp.net 2.0
& C#. This web page page contain one text box & two
button just like a page of google. Assume that text of Button
is First &...
|
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:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
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: 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...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
