|
#1
|
||||
|
||||
|
OnNextSelection , OnNullClick
Ok i realise the chances of getting these are slim but here goes..
Id like to suggest 2 extra event catagories to all current objects ;- OnNextSelection OnNullClick They are both 'De-Focus' events that would only come into effect the moment a user clicks an object and would only last for 1 click. OnNullClick - would get called if the next click from the user is on the page background. OnNextSelection - would get called if the next click from the user is an object. + maybe some reference to which object it was. For example: the user types something into an text input. Most of the time to aviod complicated checks on every key of the input the programmer is forced to add some type of 'ok' or 'enter' button. With either of these extra events the ok button could be eliminated. |
|
#2
|
|||
|
|||
|
It would be nice to have a Validate event similar to VB. Using it you can keep the focus on the control until it meets criteria you specify.
|
|
#3
|
||||
|
||||
|
It would be nice to see such events...
but until we do, you could try this (is what i do for inputs) Code:
-- Dummy Test Function
function MyReturnFunction(strText)
Dialog.Message("Test",strText)
end
-- Check if return key is pushed
if System.IsKeyDown(13) then MyReturnFunction(Input.GetText(this)) end
|
|
#4
|
||||
|
||||
|
I really need this as well, all business applications would be much easier to code with this event. I called it OnBeforeLoseFocus or something like that when I suggested this several months ago. In Delphi, this event would be OnExit.
__________________
Never know what life is gonna throw at you. (Based on a true story.) |
|
#5
|
||||
|
||||
|
With an OnNullClick event programing things like custom popup menus would be no problem at all.
|
|
#6
|
|||
|
|||
|
An action of that type would certainly be an improvment, instead of always creating work-arounds.
I may be way off-base here, or maybe I'm just getting senile, but many years ago I handled something similar to this (Imagine COBOL & CICS - OMG) by logging where the user had 'come from' on the screen/page. I used a table back then to log user screen activity, but we used the last entry to determine where the user last made an entry. The table would then be checked to make certain all fields/objects were accounted for on the screen/page. Applying this to AMS (sans table) may look something like this: Code:
--Place this On Focus or On Click for each editted object (depending on the object type)
-- example of Input1 On Focus
if PriorObject ~= nil then
Dialog.Message("Prior Field", ""..PriorObject)
-- do your edit on prior object [editfunct(PriorObject)]
end
PriorObject = "Input1"; -- now store this object name
|
|
#7
|
||||
|
||||
|
Thanks for the suggestions guys. These have been added to the list to be considered.
REF: 17140 |
|
#8
|
||||
|
||||
|
Quote:
Code:
local menu_id = Application.ShowPopupMenu(e_X, e_Y, popup_menu, TPM_CENTERALIGN, TPM_TOPALIGN, true, true); |
![]() |
«
Previous Thread
|
Next Thread
»
| Thread Tools | |
| Display Modes | |
|
|
All times are GMT -6. The time now is 06:01 AM.









Linear Mode
