copy selected field content activates page-up 1

[arielap]

This form has a 3 page pageframe; each page containing a grid. The pageup/down keys move between pages. Keypreview =.t.
The users want to be able to select part of a grid field and copy the selected text to another field (on the same page).

In development mode this works prefectly well -
ie select text, press ctrl+c, move focus to the destination field,press ctrl+v- and the selected text appears in the destination.

But NOT when compiled. Then ctrl+c does a pgDown (to the next page) instead of copying the selected text. Presumably because both pgdown and CtrlC have the same keystroke value (3).

How do I get the EXE to behave as the development version does

 

[Olaf Doschke]

The difference is: In development you have the system menu, which has the _MED_COPY and _MED_PASTE menu items. Create these menu items in your application menu, and CTRL+C/V will work as usual.

You can use the menu desinger and design a shortcut menu with the two items (chooose Copy and Paste via "Insert Bar"). Then at runtime define that popup menu, you don't need to show it for the menu items to be active.

Bye, Olaf.

 

[Mike Lewis]

Arielap,

Building on Olaf's advice, I suggest you go one further:

1. Using the Menu Designer, create a shortcut menu, with Cut, Copy, Paste, and also perhaps Clear, Select All, and similar functions. Be sure to assign these to the relevant shortcut keys.

2. In your base textbox class, add code to the RightClick method to call the menu (with a DO command).

3. Use the base textbox class (or a subclass of it) in place of the built-in textbox in your grids.

I know this is a bit more complicated than just adding a menu, but it will let you provide a standard context menu in all your textboxes, which is something your users will appreciate, plus it will solve your original problem.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[arielap]

Thanks both.
I'll go with Oleg for this app - This is the only field where ctrlC/V is wanted OR allowed

 

[arielap]

Answer was bit of both.
Created a shortcut menu with just Copy and called it from the R-click method of the field that needs that capability. So it's just R-click C to copy selected - near enough to Ctrl C to keep the users happy. (Paste still works as usual in the EXE)

Now is there a simple way to disable Ctrl C without losing the PgDn function?

 

[Olaf Doschke]

disable? CTRL+C shoudl work as usual, if you have a menu item _MED_COPY, also in a shortcut menu. Even if it's invisible at the time the hotkey is used. Unless... Have you overriden the hotkey for that menu item?

Bye, Olaf.

 

[Mike Lewis]

So it's just R-click C to copy selected - near enough to Ctrl C to keep the users happy.

But if you've done it right, you should have Ctrl+C as well. You need either to use _MED_COPY in the menu bar, or explicitly assign Ctrl+C as the the shortcut.

I'd also suggest that you add Paste and Cut to the menu, if only to make it more like the usual Windows context menu.

Other than that, glad to hear you've got it working.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[arielap]

>> You need either to use _MED_COPY in the menu bar<<
I did, and assigned ctrl C as the shortcut key label but pressing Ctrl C, even after R-clicking for the shortcut menu, still just pages down to the next page. Cut & Paste work normally & the users prefer the familiar keystrokes. (cut isn't used now they've got a Copy)

Olav
>>Have you overriden the hotkey for that menu item? <<
not specifically, but I'm using the normal Pageup/Dn keys to move between pages and PgDn has the same keycode as Ctrl C

 

[Mike Lewis]

I don't understand why Ctrl+C is causing a page down within the grid. It's not normal behaviour (is it?) Have you got some code somewhere that is doing that?

If I remember right, in MS-DOS, the PdDown key generated the same key code as Ctrl+C, but I don't see that being relevant here.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

>>> You need either to use _MED_COPY in the menu bar<<
> I did, and assigned ctrl C as the shortcut key label

Don't do that, just add the _MED_COPY item as is, don't assign a shortcut key label.

In your app, do you have Keypress Event code, which calls NODEFAULT in cae of the keycode for PageDn? Then only do so, if the nShiftAltCtrl parameter has no CTRL bit set in it. You can differentiate between PageDn and CTRL+C this way, while both have the same keycode, only CTRL+C has the CTRL bit set.

Bye, Olaf.

 

[arielap]

>>do you have Keypress Event code, which calls NODEFAULT in cae of the keycode for PageDn? <<

Yes
I've never looked into the nShiftAltCtrl parameter. How would I code for it?
the current bit of the Keypress is

if nKeyCode=3 && PgDn
nodefault
if this.pageframe1.activepage=1 && go to P2
this.pageframe1.activepage=2
GOTO cplace
else
if this.pageframe1.activepage=2 && go to P3
this.pageframe1.activepage=3
ThisForm.Pageframe1.Page3.grdPage3.Column2.txtMica.SetFocus
endif && on P2
ENDIF && which page was I on
thisform.refresh()
ENDIF && PgDn pressed

So should line 1 then be something like
if nKeyCode=3 and nShiftAltCtrl <> 2

 

[arielap]

>>I don't understand why Ctrl+C is causing a page down within the grid.
In MS-DOS, the PdDown key generated the same key code as Ctrl+C <<

and still does in VFox.

I think Olav's last post has provided the solution.

 

[Olaf Doschke]

help says it:

1 is for SHIFT
2 is for CTRL
4 is for ALT

and any combination of keys gives any combination of the values. These are bit values of the lowest three bits 0,1 and 2. You use BITTEST(nShiftAltCtrl,1) to test for Bit 1 = CTRL

So:

if nKeyCode=3 and NOT BITTEST(nShiftAltCtrl,1)
...

But you can also test for 2 explicitly, as CTRL+SHIFT+C is not copying and ALT+CTRL+C also.

The inverse logic is simpler though. If you want to test for PageDn without a modifier key, then test for nKEyCode = 3 AND nShiftAltCtrl=0, which means no such modifier key is pressed together with PageDn.

Bye, Olaf.

 

[arielap]

>> test for nKEyCode = 3 AND nShiftAltCtrl=0, which means no such modifier key is pressed together with PageDn.<<

That worked perfectly - The lab boys & girls will be much happier now, with keystrokes that do what they're used to

And I've learnt something new (after 20 odd years of Fox)

thank you so much

Ariela

 

[Olaf Doschke]

Glad it works.

What is a bit of an annoyance is, that nKeyCode itself also is modified with the modifier keys. What can be learned is: Overall it's better to test for nKeyCode in conjunction with a specific nShiftAltCtrl value. The table overview of Keycodes in the INKEY() help topic helps about the nKeyCode, and implicitly also tells you what nShiftAltCtrl value to test for.

Eg if you'd want to react to PageDn+Shift, it would be (nKeyCode=51 and nShiftAltCtrl=1), because nKeyCode=51 with nShiftAltCtrl=0 would be "3" and combinations of Shift,Ctrl or Alt would not make much sense anyway.

That complication rather comes from hardware and OS and is historical. Some of the nKeyCode modifications are more obvious than others, eg 1+SHIFT is 33, and that's simply "!", also ASC("!") is 33. But nKeyCode = ASC(cKey) is not always true, as in case of CTRL-Combinations and of course such control keys as arrow and page keys.

Bye, Olaf.

 

[arielap]

>>it's better to test for nKeyCode in conjunction with a specific nShiftAltCtrl value. <<

Thanks - I'll check the other keystrokes now, though everything except ^C worked as expected.

As you say "implicitly" - it is understandable once you know. Maybe later versions of VFP than mine are more helpful - I'm still on v7 as this app is apparently in use by labs abroad, still on '98 PCs

ariela

 

[Olaf Doschke]

This is the same in VFP9. It will not change.
The OS does offer even more complicated codes like scancodes, which have even less to do with the ascii codes, see

http://msdn.microsoft.com/en-us/library/windows/desktop/ms646306(v=vs.85).aspx

Bye, Olaf.

 

[arielap]

Pass - don't think I'll need that thanks - think I can manage with what I've just learned - for which many thanks again.

The ^C / PgDn clash was the first (and I hope now last) time I'd met a problem with keystrokes - and I've been with Fox since before MS bought it

ariela

 

[Olaf Doschke]

I was not suggesting Win API as the better alternative, just to show it's even more complicated than what VFP gives you. You might never have a problem with Keypress Events only checking for nKeyCode, where the alternative Key combination also resulting in the same nKeyCode is never used by users. But you can simply lookup if that could be tha case searching within the INKEY() help topic.

Statisitcal: The three modifier keys can be used in 8 combinations ranging from none to all three. So with a 109 keys keyboard this leads to theoretically 872 Key combinations. Most of them are never used, though. But nKeycode will mostly be below 256 and besides the few negative values for function keys, this means potentially lot's of double usages, not only for CTRL+C vs PageDn.

Bye, Olaf.

 

[arielap]

>>I was not suggesting Win API <<

So far I'd always got away with simple keystrokes, just changing the few non-intuitive ones if the keycode clashed, but it's good not to have those limitation. The program also has to run on the on-call technician's netbook - slightly different keyboard layout- but all seems fine there too now

ariela