1. next UI question
In a editText field the insert key does not toggle between insert and type
over. Is this correct? If so that's a pain in the behind...
...george
2. Re: next UI question
----- Original Message -----
From: "George Walters" <gwalters at sc.rr.com>
To: "EUforum" <EUforum at topica.com>
Subject: next UI question
>
> In a editText field the insert key does not toggle between insert and type
> over. Is this correct? If so that's a pain in the behind...
>
Yes and yes.
It is the program's responsibility to manage the meaning of the Insert key.
Windows does not offer any support in this area.
However, this is probably something that Win32lib could manage for you in
future releases.
----
Derek
3. Re: next UI question
Derek,
I would think that a functional insert would be a good option. If I were to
try this myself ( during training I wrote this in EU but not in win32) would
that mean that I would have to totally control the input field? Or is that
just a switch that we would have to send to the win api?
BTW could you explain the arguments to the shellExecuteEx? I would like to
resolve the 'bad problem' if possible..
thanks..
..george
...george
----- Original Message -----
From: "Derek Parnell" <ddparnell at bigpond.com>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, August 09, 2001 5:37 PM
Subject: Re: next UI question
> >
>
> ----- Original Message -----
> From: "George Walters" <gwalters at sc.rr.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, August 10, 2001 7:06 AM
> Subject: next UI question
>
>
> >
> > In a editText field the insert key does not toggle between insert and
type
> > over. Is this correct? If so that's a pain in the behind...
> >
>
> Yes and yes.
>
> It is the program's responsibility to manage the meaning of the Insert
key.
> Windows does not offer any support in this area.
>
> However, this is probably something that Win32lib could manage for you in
> future releases.
>
> ----
> Derek
>
> >
> >
>
>
4. Re: next UI question
> I would think that a functional insert would be a good option. If I were
to
> try this myself ( during training I wrote this in EU but not in win32)
would
> that mean that I would have to totally control the input field? Or is that
> just a switch that we would have to send to the win api?
George:
I've checked a few MS programs, as well as some Delphi-generated programs,
and none that I've checked allow overwriting an edit field. They are all in
the
'insert' mode all the time, and hitting the "insert" key does nothing.
You can select portions of the text using the mouse, and then that part gets
replaced
by whatever you type in, which I suppose is the Windows way of
"overwriting".
Regards,
Irv
5. Re: next UI question
> From: George Walters <gwalters at sc.rr.com>
> To: EUforum <EUforum at topica.com>
> Reply-To: EUforum at topica.com
> Subject: Re: next UI question
> Date: 10/08/2001 8:24:56 AM
> I would think that a functional insert would be a good
> option. If I were to
> try this myself ( during training I wrote this in EU but not
> in win32) would
> that mean that I would have to totally control the input
> field? Or is that
> just a switch that we would have to send to the win api?
I'm in no hurry to implement this functionality because it is not trivial
and there's not a lot of people asking for it.
You might have to think more about what you are trying to do with the data
in an edit field. My understanding is that most people wish to replace the
entire field data when they *first* enter the field since pressing an "ok"
type of button. If they enter the field again, before pressing "ok", they
are either going to change nothing or do some minor changes. The most common
of the minor changes is to replace zero or more characters with a string of
a different length. For example, in correcting spelling mistakes, often
people have to insert missing letters or drop extra letters. It may be
easier to just highlight the area to be changed and then replace it with new
data. Highlighting can be done with either the mouse or Shift-Arrow keys.
Another consideration is that Insert mode is safer than Overtype mode
because it is less likely to remove stuff inadvertently. Using insert mode
to replace text means that you get a visual clue (the selection is
highlighted) before you remove stuff from the field.
If you are writing a general purpose text editor, then this is a different
problem and you would require total control of the field.
I will need more input from people about how best to implement an automatic
overtype mode for edit fields.
> BTW could you explain the arguments to the shellExecuteEx? I
> would like to resolve the 'bad problem' if possible..
Sorry about the poor docs for this function. It will be improved.
This function takes six parameters and returns a result.
Parameter 1: VERB: This is nearly always the string "open". Other verbs
are available but I won't detail them just here.
Parameter 2: FILE: This is the file to open. It can be a ".exe" file if
you wish to run a program, or it can be a document file that has had an
association defined for it - in which case the assocaited program will be
started with this document file name as its parameter.
Parameter 3: PARMS: If the FILE was an .exe, then this is a string
containing the parameters (command line) to be given to the program. If the
FILE is a document, then this should be zero.
Parameter 4: DEFDIR: This is either zero, or a string containing the
default directory to be set before the FILE is opened.
Parameter 5: STYLE: This is one of the standard WIndows constants for
displaying windows. Typically it is SW_SHOWNORMAL or SW_MAXIMIZE, or
sometimes SW_MINIMIZE. Other values are available but are rarely used.
Parameter 6: STRUCT: This is not used yet. A future release of Win32lib
will use this to allow the coder to get more control over the program that
is started, including finding out if the program finished or not, waiting
until it finishes etc... These are NOT implemented yet.
Return Code: This is an integer. A value in the range 0 to 32 inclusive
means that an error occurred and the program was not started. Values above
32 mean that shellExecute did not detect an error.
Some values I know about are ...
0 -- Windows is out of resources
2 -- file not found
3 -- path not found
5 -- access denied
8 -- out of memory
11 -- The program is not a valid EXE
26 -- File sharing failed
27 -- File association is invalid
28 -- The DDE transaction timed out
29 -- The DDE transaction failed
30 -- The DDE transaction failed because other DDE transactions
were in progress.
31 -- There is no association for the document
32 -- DLL not found
Examples:
integer SE_return
SE_return = shellExecuteEx("open", "exw.exe", "myprog.exw", 0,
SW_SHOWNORMAL, 0)
SE_return = shellExecuteEx("open", "bcc32.exe", "-cO myprog.c", 0,
SW_SHOWNORMAL, 0)
SE_return = shellExecuteEx("open", "win32lib.html", 0, 0, SW_MAXIMIZE, 0)
SE_return = shellExecuteEx("open", "chapter1.doc", 0, "C:\\novel",
SW_SHOWNORMAL, 0)
-----
Cheers,
Derek
confidential information intended solely for the use of the individual or
entity to whom they are addressed. If you are not the intended recipient of
this message you are hereby notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately. Any
views expressed in this message are those of the individual sender and may
not necessarily reflect the views of Global Technology Australasia Limited.
