Caps lock ON when application activate

Can I trap the 'activate' of my app I want to turn on caps lock every time the user selects the VFP application. I don't want to do this at the start of the app because the user may minimize the app and then get back to it.

Thx.

Visual FoxPro1

Check activate event.

I am sure activate even would help me... But I am not sure where do I find the activate event of my entire application... I was thinking of puting this in the activate event of my base form class, but I thought maybe there is a better way to access the activate of my entire app.

Is there

Thanks.

If your app is using a top-level form, you can probably use that form's Activate and Deactivate method (though I'd have to test to be sure).

An alternative is to bind the Windows activate and deactivate events for the application. Check out "Binding to Windows Message Events" in the Solution Samples.

Tamar

IN THE FORM LOAD EVENT PUT THE FOLLOWING CODE

DO WHILE CAPSLOCK() =.F.

WAIT 'PRESS CAPSLOCK TO CONTINUE

LOOP

ENDDO

I don't see how would that help. I need my entire APPLICATION to turn on caps lock automatically.
Also, the loop command is entirely meaningless. You never put a loop where the next command is enddo anyway.

Why in the world would you make everything in Caps

Any form field that needs caps should have it set in the format property.

MANY USERS DON'T LIKE CAPS IN THEIR EDIT BOXES BECAUSE IT IS HARD TO READ. Don't you think

force capslock() = .T.

check the status of capslock whenever some events occur and if capslock() = .F. U FORCIBLY TURN IT ON. DISPLAY A MESSAGE UR APPLICATION WILL NOT WORK WITHOUT CAPSLOCK ON.

LOOP IS FORCE THE USER TO TURN CAPSLOCK ON, IF HE DOES'T DO THEN APPLICATION WILL NOT WORK.

THANKS

Maybe you didn't understand what Aleniko was saying. He says loop is unnecessary when the next command is enddo. ie:

do while somecondition
*....
loop && Why do you need loop here
enddo

PS: If an application wouldn't work because of caps lock is not on then I assume that application woudl never work.

The original application (And also the VFP converted one) Assumes that all DATA is entered in upper case. Searching data when the data could be entered in Caps, nocaps or any cOmBinaTion is difficult. And yes, I know I can make sure everything entered is converted to caps, but its much easier to just let the user go into caps lock.

Again: My problem is that the user can minimize the VFP app, go check his Email, turn caps lock off, and then come back to the application, and enter some info with caps lock OFF.

Thanks.

Cetin;

Please read my response to Don Higgins.

Thx.

That is an amazing amount of work for nothing.

Your searches should be on UPPER() anyway, trying to force caps lock is simply poor design and coding.

Set your code up properly by coding for this, it takes much less time to Code properly. You have wasted much more time waiting for an answer about the wrong way.

Don;

I may be wrong, but I think searching on upper is a big mistake. I think performance would suffer doing so. Are you implying that in order to take advantage of rushmore I should index everything on upper() Even so, I think doing search by specifying upper() means VFP needs to run an upper() function for every entry in the search scope.

I may be mistaken, but I think forcing the user to go upper will save me alot of headaches in design, search, query and indexes.

But I may be wrong...

thanks for your input anyway.

No, you do not need an index on upper(). You can store the data as upper if you need to by just changing one property on your textbox class.

When you search you can use :

seek(yourfield)

No need for Upper in the command as long as the field Format Property is set to "!" for upper. All the data will be stored as upper() and the index will find everything just fine.

One property in your textbox is all you need. Change the format to "!" and forget about the other stuff. If you have custom textbox class change it, then recompile and you are finished.

Hi Aleniko,

I agree partially with Don's reply to that ( if you really need to store them uppercased then set format to "!" in your base textbox class and that'd be all - however storing everything uppercased is ugly).

"I may be wrong, but I think searching on upper is a big mistake. I think performance would suffer doing so. Are you implying that in order to take advantage of rushmore I should index everything on upper() Even so, I think doing search by specifying upper() means VFP needs to run an upper() function for every entry in the search scope."

I think you're wrong. For a moment, think that upper() would be applied to each and every record. Even in that case functions like upper(), lower() are very fast that you don't care they consume time in (maybe 1 sec load for millions of records). However in the case of an index, upper() is not applied to each record. Instead VFP sees it exactly matches a key and uses index entries directly. In effect you're doing the upper() just once for a search (for the searched expression). As a plus what you gain is a defensive programming. No matter the actual storage casing is you get what you want.

So yes, I'd imply that you should create upper(),lower() style indexes for character data. Just do not forget to upper() your search expression too and use upper(fieldname) in your where clauses so rushmore can use the index. ie:

lcSearch = upper("someValue")

select * from myTable where upper(myField) = m.lcSearch

or:

if seek(upper(m.lcSearch,'myTable','myFieldTag')

...