name_info Attributes : how do they work ?

[Graeme]

My understanding of name_info attributes is a little vague and I want to understand them better.  Slick help has this example

Code: [Select]

// This command is enabled only when the target is an editor control
// which has a selection.
_command void gui_enumerate()
       name_info(','VSARG2_REQUIRES_EDITORCTL|VSARG2_REQUIRES_AB_SELECTION)
{
    ...
}

What is meant by "the target is an editor control"?  Does it mean the function can only be called during the dispatch of an event that originated from an editor control  - or can it be called (e.g. from any slick macro/function) as long as there is an active buffer in existence that may not even have the focus or be visible?

The _OnUpdate_linehex example in the help suggests that the return value of that function is used to grey out menu options if the command appears in a menu, so where does the "menu event processor" get the target_wid from that it passes to the _OnUpdate function.

Similarly, I am mystified by VSARG2_CMDLINE.  I don't understand the help file description of what this does.  I can call macros from the command line that don't have this attribute, so what does it do?

Thanks for any insight.
Graeme

[hs2]

Good point Graeme ! The docs aren't very helpful at this point.
I guess, that these attributes can/should be used to control, that your macro is in the right 'context' when getting called.
In other words: It isn't called (even when invoked by a global shortcut), if the required attribs don't match.
Imagine you've written a macro that relies on an active source buffer (editor control) and you want to do s.th. at the current cursor position. It's invoked by a shortcut, but e.g. the 'Defs'- tree widget has got the focus. You'll get a Slick stack trace as soon as you try to access an object, which is just not valid in the context of this tree widget (don't ask me for a example now).
That's just my experience... But it's worth to use'em (carefully).

Hope that I'm right (@Slickteam ?) and things are a bit clearer now.

HS2

[Graeme]

Thanks HS2.  That helps a little.  I sort of knew that but didn't have it very clear in my mind as the determination of which object is the active object at any given point was unclear to me.  I'm assuming that the slick interpreter uses the active object as the thing to check the required attributes against.

If I select some lines in an editor control, then put the focus on the defs window, then click Document on the mdi menu and do "comment lines" - the selected lines get commented, even though the focus is still on the defs window.  It seems the mdi menu driver must assign the editor window as the active object before calling the command.  Also if I bind say function key F6 to "comment lines", I can still use it when the defs window has the focus and the selected lines get commented  - I wonder where the active object gets assigned for that to work.

I tend not to use properties unqualified in my macros but I think there's a few places where I need to add some of these name attributes.

Thanks
Graeme

[hs2]

Amazing - same thoughts as me...
I re-checked the v11.01 docs and the name_info help is quite ok.
It somehow proves my assumptions.
But I miss a 'big picture' explanation for all that (default behaviour etc.).
@SlickTeam: Would be nice to see something related in the v12 docs.

It seems to me that there are 3 possibilities/levels to write solid macro code:
1. name_info attribs
2. _OnUpdate callbacks
3. manual checks/preparations inside a macro itself
E.g. you'll see a lot of:

Code: [Select]

   int orig_wid=p_window_id;
   if (!_isEditorCtl()) {
      p_window_id=_mdi.p_child;
   }
   ...
in the sources.
However, you'll get deeper into that ('active objects/windows' and their properties) when writing macros with dialogs/forms.
HS2

[Graeme]

This discussion has made me realise that the invocation option of -#some-command can be used to invoke any command at startup, not just commands that act upon the current buffer.  The help file says -# will "Execute command on active buffer"  -  which made me think the command had to do something to the active buffer ...  (I'm easily confused).  I guess it just means that the current buffer is the active object when the command is executed, but that doesn't stop the command from running a dialog box or something unrelated to the current buffer. 

In another thread where Scott W asked for feedback about restore options I suggested that specifying a macro to run at startup from the command that invokes slickedit wasn't possible - but I was wrong.

Graeme