Recent

Author Topic: onkeydown event question  (Read 30813 times)

wpflum

  • Sr. Member
  • ****
  • Posts: 287
Re: onkeydown event question
« Reply #30 on: September 08, 2010, 03:14:30 pm »
That is what I'm doing.

I'm using the form keydown event since I have to catch cursor keys so I don't handle the key presses on an object scale so that helps.  I have one keypress function on a Functions unit and I pass all of the information from the keydown event to it including the TForm object which is wat I was having trouble with.

garlar27

  • Hero Member
  • *****
  • Posts: 652
Re: onkeydown event question
« Reply #31 on: September 08, 2010, 04:48:29 pm »
OK, You have to do this:

Code: [Select]
procedure TForm1.Form1KeyDown(....);
begin
   // if you have to do things only for this form, do it before this line.
   MyKeyDownMethode(Screen.ActiveControl, Key, Shift);
end;

Code: [Select]
procedure MyKeyDownMethode(Sender: TObject; var Key: Word;
   Shift: TShiftState);
begin
   // ALLWAYS DO SAFE CASTING!!!
   if Sender is TEdit then with Sender as TEdit do begin
      // place your code here
   end;
end;

This should work!

wpflum

  • Sr. Member
  • ****
  • Posts: 287
Re: onkeydown event question
« Reply #32 on: September 09, 2010, 04:26:38 pm »
It does and that is what I'm doing.

The only reason I posted the outline of the program is that I was being told that trying to do it the way I wanted to do it with little or no logic and code in the main form was buggy and not a good thing to do.  So far no one has come forward and said 'Yes it is buggy and here is why'  which was what I was looking for at this point. If someone can provide me with good reasons why I should program like this I'd love to hear them.  :)

garlar27

  • Hero Member
  • *****
  • Posts: 652
Re: onkeydown event question
« Reply #33 on: September 09, 2010, 06:23:48 pm »
A program can work "perfect" even if it's bug prone or safe. This is a fact and believe me: I can tell you about it.

BUT if a program is is bug-prone, mantainance becomes ... a BIG PROBLEM.

Now your program seems small and those things are not an issue, but if it starts to get bigger it will. And soon you will see how a beautifull small program becomes a snowball an ends like an avalanch. This is why people say: that code is buggy. And they're right.

If you can do things right, do it right from start. The best way to solve a problem is before it happens or while it's easy. And Object Oriented Programming it's the best way to avoid those problems.
 
For instance:

You have a Form with it's Components, and a Unit with functions, And god knows where is the Data and it's methods (This shoul be a class in a sepparated Unit).

Your solution as we understood is: a Unit (wich doesn't know much of a Component's context) to handle Form's component's input. It's something like: a cab driver let passengers to drive the cab without switching positions!

A different (and better way) to do the same thing is:

Your Unit contains general purpouse procedures and functions like:
Code: [Select]
function KeyIsNumeric(Key: Word; Shift: TShiftState): Boolean;
begin
   Result := (Key in [VK_NUMPAD0..VK_NUMPAD9]) or ((Shift = []) and (Key in [VK_0..VK_9]));
end;

procedure GoToNextControl(AWinCtrl: TWinControl; GoForward, ChkTabStop: Boolean);
begin
   UnCtrl.SelectNext(AWinCtrl, GoForward, ChkTabStop);
end;

The Form:
Code: [Select]
{ Since I don't know what you check I did this... }
TForm1.Form1KeyDown(Sender: TObject; var Key: Word;
   Shift: TShiftState);
begin
   if (key = 13) and (Shift = []) then begin
      Key := 0;
      if sender is TWinControl then begin
         GoToNextControl(TWinControl(Sender), True True);
      end;
      Exit;
   end;

   if not KeyIsNumeric(Key, Shift) then begin
      Key := 0; // Erases the pressed key
   end;
end;
Note: if you need keyboard's shortcuts you can do it with TActionList Component in the standard component's tab.

If you find yourself doing the same change in many different methods and/or different units, forms, classes. Then you will know that you're in the middle of a snowball rolling down the mountain in an avalanch... and it gonna' hurt!

wpflum

  • Sr. Member
  • ****
  • Posts: 287
Re: onkeydown event question
« Reply #34 on: September 09, 2010, 06:51:54 pm »
I don't quite follow you but I think your analogy is incorrect.  From my perspective, staying with the cab driver motif, my method of programming is like having a cab driver in the drivers seat with a video camera on his head feeding a monitor for the several backseat passengers to take turns with.  The back seat passengers with the monitor tells the cab driver what to do based on the image he/she is seeing and the cab driver then steers, stops or accelerates based on that dialog. The cab drivers handles the nuts and bolts of the driving, keypress events, tab events, etc like the main form/program and the passengers handle the minutia of the where/when/how directions like is the data ok in the field you just exited and can you go to the next screen. 

I think my main problem, if I actually have one, is that this is my first time with an Object oriented language and I still try to program the old school way.  I am starting to like things like making my own class to handle and validate my data and maybe once I get a handle on that then I could twist my version of coding into something that keeps most of the stuff on the form since most of the stuff could be handled as an object thus the actual 'code' would still be off the main form but instead of functions and such I'd have classes.  Stay tuned for more, same bat time same bat channel........ ;D


 

TinyPortal © 2005-2018