1. next UI question
- Posted by George Walters <gwalters at sc.rr.com> Aug 09, 2001
- 397 views
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
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 09, 2001
- 400 views
----- 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
- Posted by George Walters <gwalters at sc.rr.com> Aug 09, 2001
- 380 views
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
- Posted by Irv Mullins <irvm at ellijay.com> Aug 09, 2001
- 406 views
> 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
- Posted by Derek Parnell <ddparnell at bigpond.com> Aug 09, 2001
- 404 views
> 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.