Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
OKL Passing Parameters
Message
From
26/06/2001 12:06:37
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
26/06/2001 08:07:30
Jay Johengen
Altamahaw-Ossipee, North Carolina, United States
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00523099
Message ID:
00523619
Views:
16
This message has been marked as a message which has helped to the initial question of the thread.
>Ok, ok... Y'all are having an awful lot of fun at my expense here! :)

Probably because we've all been there, and see another one who wants to go :).

> I wanted to do the HelpContextID, but it still means that I have to maintain and keep track of the relationship between the ID and the object. To make this even harder, the user insists to have the ability to add help for objects on the fly. This in itself is not difficult when I pass the object name and the hierarchy information, but it's impossible using the ID as it has to be manually maintained. Unless I don't understand how it is supposed to work. The ID would make sense if it were a unique number that Foxpro assigned, but as I understand it I would have to keep track of the relationship.

You can actually assign the HelpContextIDs using a builder (which is not written yet, AFAIK, but shouldn't be hard to do), using some way to assign your object unique IDs and then store those IDs and sys(1272)s into some table - which can also have a memo to keep your (html?) help text so you can go easier about building this help system.

>What IS the best way to handle help? Even foregoing the user-adding logic, doesn't it seem that there should be an easier way to automatically handle help at the object level? Or all levels?

Using the above table, you can know the object's HelpContextID, find it in the above table and do something about it - either pull the text from the memo there, or pull up an editing form to put the text there, it's up to you.

>And why is the ActiveControl unreliable? I can see that it is because even with the debugger not running it will not return a valid ActiveControl value from any of the objects on my form, but why?

ActiveControl may be .null. at anytime, if something that's not a control gains focus, at least temporarily - like a label, or a toolbar button (which doesn't really get focus, but I'm not sure your control on the form is still the active control until the toolbar's code finishes), while there's a MessageBox, and while debugger is up.

It's still usable, just check it - so the part in the form's keypress would be:
if isnull(thisform.activecontrol) 
    nodefault
else
    thisform.GoAheadAndHelpYourUser with thisform.activecontrol
endif
>...and thanks for allowing me to be the straight man earlier... :)
>
>Renoir

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Reply
Map
View

Click here to load this message in the networking platform