klaus filip

there is a message to max, that opens the max-window:

a similar message for the cluewindow does not work.

is there any non documented message to open the clue window?

there is a message to max, that opens the max-window:
;max maxwindow

open-clue-window-by-message

If you're on a macintosh you can use applescript to the [shell] object:

osascript -e 'tell application "System Events"' -e 'tell process "MaxMSP"' -e 'tell menu bar 1' -e 'tell menu bar item "Window"' -e 'tell menu "Window"' -e 'click menu item "Clue Window"' -e 'end tell' -e 'end tell' -e 'end tell' -e 'end tell' -e 'end tell'

but i would need something that works on mac AND windows.

thanks luke,
but i would need something that works on mac AND windows.
best
klaus


I'm not sure if it will help in your case but you could set a keyboard shortcut to achieve it. You'd need to modify the maxinterfaces.json file, search for the clue window section and include something like 

 at the end. You'll need to restart max for the changes to take effect but then the keycode will appear in the toolbar.

I'm not sure if it will help in your case but you could set a keyboard shortcut to achieve it. You'd need to modify the maxinterfaces.json file, search for the clue window section and include something like "shortcut" : "shift+C" at the end. You'll need to restart max for the changes to take effect but then the keycode will appear in the toolbar.

this helped me to find the right keyword:

thanks a lot !!
this helped me to find the right keyword:

hello, thanks for the news, but i need compile a standalone application, it seems work not properly. The clue window, can be used on a standalone application?

hello, thanks for the news, but i need compile a standalone application, it seems work not properly. The clue window, can be used on a standalone application?
thanks regards


well i only can confirm, that ;max showclue does not work in a standalone.

i even tried with including all the cycling74 folder...

well i only can confirm, that ;max showclue does not work in a standalone.
wherease ;max maxwindow works.
i even tried with including all the cycling74 folder...


The clue window doesn't work in the runtime version as far as I am aware. You can include tooltips that work in a similar way by opening an object's inspector and typing something in for the "hint" attribute. This will be shown when a user holds the mouse pointer over that object.

In the next incremental, you'll be able to display the annotations of objects in the clue window for runtime and standalones. Thanks for mentioning it.

actually i'm already using the hint, but my GUI it's small and dirty too much, :-)

I'd saw a Max standalone app, have an hint windows analogue to clue, probably it's done with Jitter?!?!

can I cite the name of the app on the forum?

thanks for the answers, great
actually  i'm already using  the hint, but my GUI it's small and dirty too much, :-)
so i look for a better way to make it.

I'd saw a Max standalone app, have an hint windows analogue to clue, probably it's done with Jitter?!?!
can I cite the name of the app on the forum?
ape


Emmanuel, you work for c74, don't you? Are you able to say about when the next incremental will be available with this feature for standalones?

Emmanuel, you work for c74, don't you? Are you able to say about when the next incremental will be available with this feature for standalones?
T


You could quite easily roll your own. Try naming the target objects, then use [hover] to pick up when they are being moused over. Enter the data you want displayed along with the varnames into a [coll] and hook this up. You could fairly easily display this in a pop up window.

Yes it is easy (to patch), but potentially tedious to implement if you've got a lot of ui objects to document with clues for the user. Adapted from hover help file:

Yes it is easy (to patch), but potentially tedious to implement if you've got a lot of ui objects to document with clues  for the user. Adapted from hover help file:


ok!
thanks Luke
thanks Terry
thanks Emmanuel


You could use [pattr] to bind to the hint attribute rather than adding something into the [coll] for each object, not that this speeds things up very much. If you desperately need this functionality you could always parse the data in the "digest" tag from the maxref XML files and then store and display it however you like.

Very cool, the "hint" attribute is great but limited to one line. BTW if you want to turn hints off, you can send the object (that you want the hint for) the message "hint 0". Otherwise, you can programatically send (hint "my hint for this object" ) and it'll be ready to go. Note the need for quotes to keep your hint line as a single symbol.

With several [coll] objects, each with a list of hints, you can very easily create multi-language hints too... and not need to access every object to change the hint, you just change the [coll] entries. The object in question grabs the hint from the right [coll], using a gate which the user selects from a dropdown: "English/Spanish/French/Portuguese", and the right index number for the object.

Although I'm not at all sure how to go about dealing with special characters like the "c cedilia" or other accents. Any details on this would be helpful, I'd like to make a [coll] for hints and translate the hints to at least Spanish.

In which environment this clue windows will work effectively?

"if you want to turn hints off, you can send the object (that you want the hint for) the message "hint 0""

this does turn hints off, but unfortunately as far as I can see, permanently.

It seems to delete the hint of the object that message is sent to. It deletes the hint rather than disabling it, so it cannot be reenabled later on. It would be great if this was changed in the next incremental so that the message (hint 0) _disables_ hints and (hint 1) reenables them.

seejay,
"if you want to turn hints off, you can send the object (that you want the hint for) the message "hint 0""

this does turn hints off, but unfortunately as far as I can see, permanently. 

It seems to delete the hint of the object that message is sent to. It deletes the hint rather than disabling it, so it cannot be reenabled later on. It would be great if this was changed in the next incremental so that the message (hint 0) _disables_ hints and (hint 1) reenables them.
T


seejay was talking about the hint object, not the hint attribute of every objects.


Oh, OK, thanks for clarification Emmanuel.

But would it be possible to have the hint attribute of any object with the ability to be enabled/disabled (without being deleted), or even have its message able to be changed? This attribute could then be accessible by the pattr system (I imagine it would make the hint object pretty much redundant in some applications).

I'll log that as a feature request but it's unlikely that it's going to happen in a foreseeable future for the reason you mentioned.

open clue window by message?