New tools for Studio users

[cncb]

I don't know how I got that funky version of your JAR file but that was it, of course. Thanks again.

[evilpenguin]

I'm not sure when this problem started occurring, but for some reason a "ref>>theme:..." that used to link properly stopped working.

If you look in the attached "theme.jpg" all three of the themes are set up the same way, however, if you look at the attached "unlinkedtheme.jpg" you can see that after the import only two of them linked properly. The other one, "MultipleOptionsTheme" just seems to link to itself as when I highlight the references it shows it linked to all of the other "MultipleOptionsTheme" from the STVi, but is unlinked to the "MultipleOptionsTheme" from the main STV.

Any ideas would be greatly appreciated.

[dflachbart]

Originally Posted by evilpenguin

I'm not sure when this problem started occurring, but for some reason a "ref>>theme:..." that used to link properly stopped working.

If you look in the attached "theme.jpg" all three of the themes are set up the same way, however, if you look at the attached "unlinkedtheme.jpg" you can see that after the import only two of them linked properly. The other one, "MultipleOptionsTheme" just seems to link to itself as when I highlight the references it shows it linked to all of the other "MultipleOptionsTheme" from the STVi, but is unlinked to the "MultipleOptionsTheme" from the main STV.

Any ideas would be greatly appreciated.

Greg's theme linking requires unique Theme names in the STV. I just checked, and there are indeed two "MultipleOptionsTheme" themes in SageMC, and the import seems to link to the 'wrong' one. I will fix this in the next SageMC version.

Dirk

[GKusnick]

You could work around it by manually editing the STVI after export to specify the full path to the correct theme. But the idea of not using full paths for themes was to make it more robust by eliminating path dependency (on the assumption that theme names are unique).

[evilpenguin]

Originally Posted by flachbar

Greg's theme linking requires unique Theme names in the STV. I just checked, and there are indeed two "MultipleOptionsTheme" themes in SageMC, and the import seems to link to the 'wrong' one. I will fix this in the next SageMC version.

Dirk

Strange, my search kept only turning up one "MultipleOptionsTheme" from the SageMC options menu. Where's the 2nd one?

Originally Posted by GKusnick

You could work around it by manually editing the STVI after export to specify the full path to the correct theme. But the idea of not using full paths for themes was to make it more robust by eliminating path dependency (on the assumption that theme names are unique).

Thanks, that'll fix it for short term.

[jphipps]

I am trying to build an STVI and in the code, I want to find and remove a Menu tree. I put the below in the STVI, but it gives me method not found errors... I am sure I am butchering the syntax somewere:

menu = gkusnick_sagetv_api_WidgetAPI_FindWidget("MenuName")
menu_DeleteTree(true)

What would the correct syntax be to remove an entire widget tree?

Thanks,
Jeff

[GKusnick]

Page 150 of the Studio manual explains the rules for calling Java methods from Studio code. Basically you need to spell out the fully qualified name of the method, including package name, using underscores in place of dots. You also need to pass in an instance of the class whose method you're calling. So for example your calls to FindWidget and DeleteTree should look more like this:

"REM Get an instance of WidgetAPI somehow."
widgetAPI = ???

"REM FindWidget takes two arguments, Type and Name, in addition to the widgetAPI instance."
widget = gkusnick_sagetv_api_WidgetAPI_FindWidget(widgetAPI, "Menu", "MenuName")

"REM Spell out the fully qualified method name, and pass in the widget instance."
gkusnick_sagetv_api_WidgetAPI_Widget_DeleteTree(widget, true)

There are ways to get a WidgetAPI instance from Studio code, but I'm not going to go into that, because that's doing it the hard way. A better way is to use the STVI.RemoveWidgetEx method provided for just this purpose:

gkusnick_sagetv_studio_STVI_RemoveWidgetEx(stvi, "Menu:MenuName")

In this case the stvi instance has already been created for you by Export As STVI, so you don't need to worry about where to get one. "Menu:Menu Name" is the widget path to your menu, which you can get by right-clicking the menu in Studio and choosing Plugins > GK Tools > Copy Widget Path. (Or you can just type it in if it's short enough, like this one.)

[jphipps]

I tried both of those and I recieved the following error int he debug log:

Tue 2/19 14:30:34.275 Module processing STVImported Hook
Tue 2/19 14:30:34.381 Parsing Error: Unexpected "," at column 57.

Expression: gkusnick_sagetv_api_WidgetAPI_Widget_DeleteTree( Widget , true )
Tue 2/19 14:30:34.822 UIMgr loading UI from: C:\Program Files\SageTV\SageTV\STVs\SageTV3\SageMC_169-44.xml
Tue 2/19 14:30:35.125 EventThread-SAGETV_PROCESS_LOCAL_UI Hang Detected - hang time = 750

I have attached a screen shot of the code. Could it be because I am trying to delete the same named menu's that I am trying to import?

Thanks,
Jeff

[GKusnick]

My mistake. You need to use $ instead of _ for the inner class, like so:

gkusnick_sagetv_api_WidgetAPI$Widget_DeleteTree( Widget , true )

That said, you don't want to be using both deletion methods at the same time. Pick one or the other. Again, the one I'd recommend is RemoveWidgetEx, since it can be done in one line without having to instantiate anything.

There are a number of other problems with this code as well. You have a call to RemoveWidgetEx, using the instance variable stvi, before that variable is initialized, which obviously isn't going to work. The widget path in your second call to RemoveWidgetEx isn't quite right (the widget type is missing); when in doubt, use Copy Widget Path to generate the correct path. You also have the call to ProcessImportEx coming last, for no good reason that I can see. Generally you want that to happen first, with your calls to RemoveWidgetEx coming afterward, unless you have a good reason for doing otherwise. (Otherwise you risk deleting too much.)

In general, this code does not look like it was generated by Export As STVI; it looks like something you copied from an existing STVI and then pasted new code into more or less at random. My suggestion would be to follow the instructions in the docs, create a dummy STVImported hook under one of your menus containing just your RemoveWidgetEx calls, and let Export As STVI generate the rest of the code for you.

[jphipps]

I put the 3 RemoveWidgetEX statements into the STVImport hook and re-exported the STVI from Studio into a new import file. If I run it with a clean SageMC-169.xml file, the one remove that should work does, and everthing imports as it should. IF I re-import into the new STV file that already had the code in it, the 2 menus and the 1 IF statement are all doubled, and the Remove does not seem to remove anything. The log shows java.lang.reflect.InvocationTargetException exception right after the call to RemoveWidgetEx. I included a copy of the new code and the log file. Sorry to be such a pain, but I really appreiciate your help...

Thanks,
Jeff

[GKusnick]

Originally Posted by jphipps

IF I re-import into the new STV file that already had the code in it...

The tools aren't really designed to allow re-importation of an STVI over top of itself. I guess I didn't pick up on the fact that that's what you're trying to do and that these are your own imported menus you're trying to remove. See post #108 of this thread for more info on this.

[jphipps]

Thanks for all of hel pon this... I will try not to be too tidy in the future...

Thanks,
Jeff

[Opus4]

I've been using the Studio.hotkeys file for just the Search & Replace functions, like in the example except for changing the keys. I finally decided to take the time to add more keystrokes for the right-click context menu. I see the keystroke shortcut displayed on that pop-up menu, but the menu item doesn't activate when I use that keystroke.

Here's an example definition:
GK\ Tools/List\ Widget\ References=alt shift L

I've tried other keystrokes, such as moving the one for searching to this item to see what happens. Do I have a problem with the definition line or does this not work for the right click menu? Thanks.

- Andy

[GKusnick]

If it shows up in the menu, then you have the syntax right. However I can't get it to actually do anything either. Obviously it works for things like Ctrl-L in the first-level right-click menu. So maybe it has something to do with being three levels deep in the right-click menu hierarchy.

I'll play with it some more tomorrow to see what else I can learn, but right now I'm as mystified as you are.

[Opus4]

OK - let me know what you find. I'm a procrastinator or I would have played with the pop-up menus long ago.

BTW: I think I understood the docs to mean that you can only customize hotkeys for your menu items, right?

- Andy

[GKusnick]

I found this remark in the Java tutorial on How to Use Menus:

Note: Because popup menus, unlike regular menus, aren't always contained by a component, accelerators in popup menu items don't work unless the popup menu is visible.

Experimentation bears this out. I can't get accelerators to work in any level of popup menu (even the first level) unless I first use the mouse to make the menu visible.

The odd thing is that accelerators do work on the stock right-click menu items (e.g. Ctrl+E to expand a node). So there must be some trickery going on in the Studio UI manager to get around that somehow. I did notice that if you type Ctrl+Shift+L as an accelerator, it activates the Properties command (Ctrl+L). This does not happen for items on the top menu bar (e.g. Ctrl+Shift+F does not activate Find), which perhaps supports the theory that Studio is doing its own accelerator dispatch for popup items it knows about.

So it looks for now like accelerators aren't going to work on right-click items, unless I have some brainstorm about how to make them work.

Originally Posted by Opus4

BTW: I think I understood the docs to mean that you can only customize hotkeys for your menu items, right?

Studio.hotkeys applies only to menu items managed by my Studio plugin manager. So if someone else creates a Studio plugin using my framework, Studio.hotkeys will work for that plugin too. But it doesn't work for the stock Studio menu items, only for plugin items.

[Opus4]

Originally Posted by GKusnick

The odd thing is that accelerators do work on the stock right-click menu items (e.g. Ctrl+E to expand a node). So there must be some trickery going on in the Studio UI manager to get around that somehow. I did notice that if you type Ctrl+Shift+L as an accelerator, it activates the Properties command (Ctrl+L). This does not happen for items on the top menu bar (e.g. Ctrl+Shift+F does not activate Find), which perhaps supports the theory that Studio is doing its own accelerator dispatch for popup items it knows about.

Oh yeah, I noticed that about Ctrl+Shift+L too, but forgot to mention it -- I probably thought I was just configuring it wrong.

So it looks for now like accelerators aren't going to work on right-click items, unless I have some brainstorm about how to make them work.

Oh well, it at least speeds up getting to the search dialog, which I use constantly. Thanks for checking it out, though.

- Andy

[beelzerob]

I just noticed this in a logfile:

EXCEPTION java.lang.NullPointerException AT gkusnick.sagetv.api.Global.IsFullScreen(Global.java:708)

I'm just calling IsFullScreen() on an instantiated sage api global object. I'm sure the object isn't null, or it would have complained in my code and not yours.

It didn't seem to crash anything either. Is there any way I can help track down what this is or was, or should I just fuggedaboutit?

[GKusnick]

Originally Posted by beelzerob

I'm just calling IsFullScreen() on an instantiated sage api global object.

Don't instantiate the Global class; instantiate the API class and use api.global to access the Global object. Otherwise that object won't get initialized correctly.

[beelzerob]

Originally Posted by GKusnick

Don't instantiate the Global class; instantiate the API class and use api.global to access the Global object. Otherwise that object won't get initialized correctly.

great, thanks!