Subject Re: [IBO] iboBars Shortcut
Author Paul Gallagher
What I am planning on doing is using ExpressBars with IBO. Nothing wrong
with the IBO bars, but they just don't work well in the ExpressBars
paradigm. Andreas Pohls suggestion is a good idea, I was planning on
something similar. In my case I am going to catch the button states with the
OnBUttonsStateChanged even. I will just drop a NavBar on the form, but set
its Visible property to false. I will use actions connected to the
ExpressBar buttons to click the buttons of the invisible NavBar. The
shortcuts are just set as properties of the actions.

This will work, but it's kind of convoluted. I wonder if I could just tie
directly into something without having to have an invisible NavBar on the
form? For example, instead of:
if Sender = first1 then ib_NB.BtnClick( nbFirst );
could I have something like
if Sender = first1 then FocusedDataset.First;

Perhaps its more trouble than its worth, but its just a thought.

Paul Gallagher

----- Original Message -----
From: "Michael L. Horne" <guardian@...>
To: <>
Sent: Wednesday, February 28, 2001 5:45 PM
Subject: RE: [IBO] iboBars Shortcut

> Hello
> It just happened that I was working on some code to setup
> shortcuts for a form I was working on.
> Some thoughts on design to start with:
> 1. Should it append or insert?
> 2. If in insert mode and at EOF file on scroll down should
> it insert a new record.
> 3. If scrolling and in insert mode and no changes had been
> made then should I cancel the insert? Or post an empty record?
> 4. Place the code in the FormKeyDown where it can be checked
> for each component to see if the keys should be processed.
> Or build into a component that hooks to a dataset and monitors
> keyboard messages. Automatically processing the commands for
> for that dataset if in a component that is attached to it
> when the key is pressed?
> 5. Should what happens on key press match what exactly happens if
> a button on the NavagationBar or the UpdateBar is pressed?
> 6. Should I create my own code or talk Jason into making/using
> some modifications to the way the bars work.
> 7. How would I design a component that could determine on all
> types of components what dataset they where attached to?
> 8. Should I just convert the code like this that I wrote for
> TTable and be done with it.
> What are your thoughts?
> ----------
> My first thoughts where lets do the simple thing, something like:
> procedure TformShipTo.FormKeyDown(Sender: TObject; var Key: Word;
> Shift: TShiftState);
> begin
> // NOTE: 17 value of Key with only CTRL pressed
> if (ssCtrl in Shift) and (Key <> 17) then
> begin
> case Key of
> VK_UP: begin NavBarShipTo.BtnClick(nbPrior); key := 0; end;
> VK_DOWN: begin NavBarShipTo.BtnClick(nbNext); key := 0; end;
> VK_HOME: begin NavBarShipTo.BtnClick(nbFirst); key := 0; end;
> VK_END: begin NavBarShipTo.BtnClick(nbLast); key := 0; end;
> VK_DELETE:begin UpBarShipTo.BtnClick(ubDelete); key := 0; end;
> VK_INSERT:begin UpBarShipTo.BtnClick(ubInsert); key := 0; end;
> end;
> end;
> end;
> end;
> But I quickly found that if I tried to scroll beyond the displayed rows
> I got exceptions like E_BEGINNING_OF_Dataset, so I added a little more
> VK_UP: begin
> if (NavBarShipTo.Buttons[nbPrior].Enabled) then
> NavBarShipTo.BtnClick(nbPrior);
> key := 0;
> end;
> This solved that problem but, also, needed to check to see if I was
> in Insert mode, if so then when scrolling I needed to check to see
> if the record had been modified if it had NOT then I didn't want to
> post the empty record, I wanted it to cancel. If I was scrolling up
> cancel/prior worked fine, if I was going down then just cancel. Of
> course if the record had changed then I wanted to post and go to the
> previous or next record.
> As you can see this gets more and more complicated.
> I am going to convert the code that I wrote for TTables to work with
> IB_Datasets. It will handle the job, but I am not sure it is the
> best result. I will post this section of code to the News Group
> Tonight or Tomorrow.
> I look forward to reading your thoughts on the problem.
> Michael L. Horne
> Your use of Yahoo! Groups is subject to