Issue with Shortcut .MPR Menu

[TGrahmann]

DEFINE POPUP quicksetst SHORTCUT RELATIVE
USE CAD00!ustat
PUBLIC nustats as Character

FOR x=1 TO RECCOUNT()
USE CAD00!ustat
GOTO x IN ustat
nustats=ustat.name
DEFINE BAR x OF quicksetst PROMPT ALLTRIM(ustat.name)
ON SELECTION BAR x OF quicksetst do setstat with nUnit,name,""
ENDFOR

-----
Does anybody see any issue with the above code? When it comes time to run the command "do setstat with nUnit, name -- nUnit is a public variable set in another form, "name" is a field in a table called "ustat" inside CAD00

Thanks!

 

[TGrahmann]

Update**
The command is not running right, the command always returns where the name variable submitted to setstat is equal to the last record of ustat

 

[Nigel Gomm]

the substitution of nUnit and name happen when the bar is selected..... by which time the record pointer is at eof()

instead try something like this

private m.lnBar
m.lnBar = 0
DEFINE POPUP quicksetst SHORTCUT RELATIVE
USE CAD00!ustat
scan
DEFINE BAR (recno()) OF quicksetst PROMPT ALLTRIM(ustat.name)
endscan
on selection popup quicksetst m.lnbar = bar()
activate popup quicksetst
if m.lnBar > 0
go (m.lnbar)
do setstat with nUnit,name,""
endif


(untested)

hth

nigel

 

[TGrahmann]

Nigel, that works great, but it doesn't place the menu at the location of the cursor. Any way to do this?

 

[TGrahmann]

I've figured it out. Method works great! Thanks Nigel!
-Ty

 

[Olaf Doschke]

OK, nigel changed your direct call to just getting the bar number into a variable, the action then happens after the shortcut item was picked.

Well, you can make that literals you pass on, so you don't have to go to the record in the ustat.dbf after creating the menu anymore:

lcName = ustat.name
ON SELECTION BAR x OF quicksetst do setstat with nUnit,"&lcName",""

This way is one of the seldom cases macro substitution within a string makes sense, because at the time of executing the ON SELECTION you define what later happens, and later you are not at the record, so you really have to put the record content of the field name into the command defined for the popup bar action. And to get macro substitution to work the field has to become a variable here, first.

There's one simpler solution though, as ustat.name is the prompt name of the menu, simply use the PROMPT() function:

ON SELECTION BAR x OF quicksetst do setstat with nUnit,Prompt(),""

Bye, Olaf.

 

[Mike Lewis]

Now that the main problem is solved, there is another (minor) issue with your code. You are executing [tt]USE CAD00!ustat[/tt] each time round the loop. That doesn't make sense. The USE statement opens the table. Once it has been opened, you don't need to keep on opening it. You just do it once before the loop start.

Of course, there is also the whole issue of the [ignore](mis-)[/ignore]use of public variables, but I'll leave that for others to discuss.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

TGML turned your [ignore](mis-)use[/ignore] into a smiley, Mike. Put ignore tags around it and the smiley will be gone.

Bye, Olaf.

 

[Olaf Doschke]

About the topic of a public variable: If I accept for the moment this is your best idea about transferring that value to everywhere it is needed, then why on earth are you using a public variable as a parameter value?

Any code can use the value of a public variable, there is no need to pass its value around. Even if the parameter name is differing from the public variable name and that PRG is not generally working with the public variable value, you can make the public variable the default value for a non passed-in parameter value, just set para=EVL(para,publicvar) to let the public variable be a default value. Then make the call with a skipped parameter, so .F. (an emtpy value) arrives and EVL then turns that to the public variable value.

So making this value public is a bad choice in the first place for very general reasons about best programming practices, but if making that bad choice not making use of it is even less sane.

Read a langthy discussion about the topic here:

http://fox.wikis.com/wc.dll?Wiki~DisappearingPublicVars

Bye, Olaf.

 

[Mike Lewis]

TGML turned your [ignore](mis-)[/ignore]use into a smiley

Well I'll be durned. I never knew that. But then I've never had any inclination to use smileys.

Anyway, it's fixed now. Thanks.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

TGML is a bit of a bad implementation of a substitution concept. TGML really is just looking for [ignore]s-)[/ignore] (it can be seen, when you hover the smiley and look at its alt text) and turns that into the smiley GIF, no matter if this is part of a text or not. I also accidentally had combinations of letters and brackets turning into smileys. The TGML mechanism should look out for white space surrounding the smiley TGML shortcut.

Even ignore has its problems. If you put f[ignore]orum184[/ignore] into an ignore tag it still is expanded to forum184. the solution is to let the ignore tag start anywhere in the middle, so the parsing for expressions to expand to links is not seeing it. The ignore tags here simply split the f[ignore]orum184[/ignore] word without any visual appearance or other influence of the tags themselves.

It hints on the flaw ignore is not processed as top-level TGML tag and link checking has priority. It may be argued to be a safety measure, so you cannot put any malicious things within the ignore tags and finding valid links and their expansion then only is an unfortunate side effect.

Last not least while TGML means Tecumseh Group Markup Language and is a self-invented BBCode concept, I am pretty sure this whole forum is based on a forum system tek-tips and eng-tips enhanced within the extensibility of the system and this is an underlying bug they hardly can fix without writing a totally new system.

Bye, Olaf.

 

[Olaf Doschke]

One further thing to learn is not only about [tt]ON SELECTION BAR X OF menuname[/tt] but about any ON <<event>> declaration of later event behavior: The part after the initial event is taken as is and only executed later ON the happening of the event.

ON ERROR ? _screen.caption
sdjkfhsdkhfjksd
_screen.caption = "help!"
sdjkfhsdkhfjksd

Whatever current screen caption is printed on the event of an error occurring. Not the screen caption as it was when the ON statement defined the action.

And that also explains why you only get the right call with the last shortcut item, doesn't it? Taken from that perspective of you noticing this behavior you already had found that answer yourself. Your code is only executed at event time and only executes with the current name value.

The definition of the bar and it's prompt (the text displayed in the menu item) in contrast is - as you can see from activating the menu, taken from each records data at definition time:

DEFINE BAR (recno()) OF quicksetst PROMPT ALLTRIM(ustat.name)

Since you GO to records (or using Nigels code scan the table) at the time of these definitions all your items show the ustat.name as their text. PROMPT() will be that value too, later on SELECTION of the item (or BAR). DEFINE BAR has no part or section of the command, that is taken literally as is and only executed at the activation of the menu. If that would be the case you would have a hard time defininig menu items with different text via data or variables, you would only be able to have different string literals. The PROMPT() function accounts for that problem.

Bye, Olaf.