How to programmaticly synchronise a checkmark in menu

[Nifrabar]

Hi!
I'm having a menu-item witch toggles the request for confirmation of saving changes.
Therefore I am using an global app.object.
Code herefore:

IF VARTYPE(oApp) = "O"
oApp.lConFirmEdit = !oApp.lConFirmEdit
SET MARK OF BAR 1 OF opties TO oApp.lConFirmEdit
ENDIF

I am going to save that setting once the application quits.
But how to inform the menu at start-up so the checkmark is there in time?

-Bart

 

[Mike Lewis]

Bart,

You don't want to save the actual checkmark. You want to save the current setting of oApp.lConFirmEdit.

Then, at application startup, just execute the SET MARK command, as in your existing code.

How you save oApp.lConFirmEdit is up to you. I would use a global settings table, but you could also save it in an INI file, the registry, or a MEM file.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Nifrabar]

Mike,
The code :
IF VARTYPE(oApp) = "O"
oApp.lConFirmEdit = !oApp.lConFirmEdit
SET MARK OF BAR 1 OF opties TO oApp.lConFirmEdit
ENDIF
that's in the procedure of the menu-item.
But at start-up, once oApp.lConFirmEdit = .T. I don't know how to set the checkmark.
Do I have to 'inform' the menu from the main.prg? If so, how to?

This moment the checkmark is not there while oApp.lConFirmEdit = .T.

-Bart

 

[Scott24x7]

Nifrabar,
I use this to indicated if the user has "Tooltips" set on or not. In the "Tooltip Status" menu, I have the following procedure:

[/code]
plMarked = MRKBAR('System', BAR())
*
IF NOT plMarked
SET MARK OF BAR BAR() OF SYSTEM TO .T.
glTipState = .T.
ELSE
SET MARK OF BAR BAR() OF SYSTEM TO .F.
glTipState = .F.
ENDIF
*
IF NOT USED('STARTUP')
SELECT 0
USE STARTUP
ENDIF
SELECT STARTUP
REPLACE STARTUP.GLTIPSTATE WITH m.glTipState
USE
*
MESSAGEBOX('Mouse Hover Tips are now set ' + IIF(glTipState,'On', 'Off'),64,'Tool Tips Help')
[/code]

I have a Global Variable plMarked which is set in the my main.prg, so is established BEFORE the mainmenu.mpr is called.

Then, when you select the item, it will change the mark status. I also save the "Last Preference" automatically so the next time my user logs on, it keeps the state they had for tool tips last time.

Hope this is what you are looking for.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Bart,

All you have to do is to execute this command:

SET MARK OF BAR 1 OF opties TO oApp.lConFirmEdit

Do that in your startup routine, any time after you have launched the menu (after your DO xxx.MPR command).

Does that answer the question?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Nifrabar]

Scott,
Thanks for your comprehensive example on this topic. Before I did not use that often menus this way.

Mike,
Yes, indeed my question has been answered now for I was unaware to be able to give the command 'SET MARK OF BAR 1 OF opties TO oApp.lConFirmEdit'from the main.prg.

Thanks for your time !!
-Bart

 

[Scott24x7]

Mike,
I agree, but I'm also using the same global memory variable at the object level used by the form to indicate of tool tips for any objects should be shown. It's good in this case, that they are all syncronized... don't know what Bart is doing with his, but hopefully this will show how to use it, rather than just setting a mark, which accomplishes only visible result, not tied to an actual state.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Nifrabar]

Scott,
For years I'm maintaining an application which didnot had a menu.
Instead just on a main-form an optiongroup for main selection and commandbuttons for the several choices.

Recently I started to rewrite all code for, as it was my very first project with VFP, it had began to be 'spaghetti'.
Also I used as base some Access-tables which I had inherited from a former programmer with uncommon fieldnames.
So :
A good reason to start from scratch, also keeping in mind that my first code was far from multi user.

Back to your issue:
I used to have some global vars for the settings which are stored in an ini-file. In my new app. I also started using the so called GOD-class (name GOD is mentioned in 1001 things). So I also have to figure out what now is best way to save user's presettings.

Regarding the menubar:
Would it be possible to give a bar an unique reference instead of bar x from yyyyy.
I feel that once the menu is updated with more choices in between things might eventualy go wrong.
-Bart

 

[Mike Lewis]

Bart,

I've tried several different approaches to saving user settings. Right now, my preferred method is a Settings table. I use it to store user preferences, the state of the user's desktop on shutdown (so that I can restore it on startup), and quite a lot more.

I have a single Settings table that is shared by all users. The record includes the user ID, a name for the setting, and its current value.

I also have a Settings Manager class. This is responsible for updating the table and for telling the application the current value of a given setting. The structure of the table is entirely encapsulated by the Settings Manager -- nothing else in the app knows of its existence.

I've tried other approaches. In one application, I used the registry, and that worked quite well, but I find my present approach a bit easier. Of course, the advantage of a Settings Manager class is that you can change your mind about the storage mechanism without upsetting the rest of your code.

Re your question about menu bar numbers .. As far as I know, these have to be numeric, and they have to be hard-coded in the DEFINE BAR command. I suppose you could define the numbers with #DEFINE, which would be a bit easier to work with, but it is still a bit of a hassle.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

I use a settings table of sorts as well... it also the users table, and locks their record, so that only one log-in at a time is allowed. It is easy to maintain as well, keeping all logical settings in one place. (You've seen an example of how one such table gets updated.)



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."