Hi Dirk,
Using v1.3. Works great ! :clap:
thanks,
Chris

I'm making an assumption that I hope is true with these utility functions. For Listener widgets it uses either the Widget Name or the ListenerEvent property when using findWidget, findExistingWidget or findImportedWidget. The reason I ask is that while some Listeners have both not all do. I have found some with just the property and some with just a name so you can't even count on the ListenerEvent property always being present. For example the Left command in the ARAdjustZoom menu in the default STV has the name Left but the ListenerEvent is blank. So is my assumption valid?

Thanks.
BobP.

Hi Bob,

yes your assumption is correct :)

GetWidgetName() (which is used by the implementation of all find...() methods) first looks at the name, and if this is empty, returns the ListenerEvent property.

Dirk

Possible bug but maybe it's just me.

Code first:
Obviously I can make this work by just using findExistingWidget and I'm converting my code now but if you can reproduce this and it really is a bug I thought you would like to know about it.

Now for the problem:
The problem is that I get a Java error - sorry it's as a graphic (in zip) - too much to write. Also included is my log file from SageTV and the import itself. All in the same Zip file. The code has no problem on the first import. NO Java error. But when I re-import I get the included error.

Edit: Opps forgot SageMC 6.6 and 1.3 of this import utility.

Thanks.
BobP.

Hi Bob,

my Internet connection was down all evening, but I'll have a look at it tomorrow. Thanks for the detailed description.

Dirk

No rush. I'm just coding around what may just be my problem anyway.

BobP.

I think I have a clue now as to why it didn't work for me. I have multiple links to widgets that existed in the STV before the first import. I unlinked them and reestablished the original links in an attempt to return it to what the STV was like before the first import. However I still have some left over links from the code in "Imported Nodes" to those objects. I then proceed to try to import new code and link it up and in the process it executes the code you had in the template for removing the old hook. I'm thinking my problem is that I need to unlink all widgets from those that I linked back into the STV and this problem might go away. I'm going to test this theory out tomorrow night when I get home from work - too late to start now.

If you do look at this maybe you will see what I did wrong if you get to it tomorrow. Also if you need anything else let me know but I really think it is just me and I'm just not using your routines correctly.

Thanks.
BobP.

PS I'm taking a CBT on Java but other than what I've seen so far and in Studio it's still a foreign language. If it was COBOL I would be better off since that is what I do all day.

One last note on this. I did get all of my findWidget's converted to findExistingWidget's and that got rid of the Java errors but it still won't import correctly it actually destroy's the main menu - as in it is broken apart into multiple root level entries. As far as I can tell it should re-import correctly so anything you can suggest would be great.

Thanks.
BobP.

Bob, got my emails I sent this morning ?

Hi Bob,

I think I found the problem in your code: you are deleting your old existing menu before calling the defineLink() methods, this way deleteWidgetTree() does not know about your linked widgets and will not stop deletion on widgets of the original STV you linked to ...

After changing the order of defineLink() in your import I noticed the next issue: the defineLink() does not work for some widgets when re-importing, because the original target widget has been replaced with a different one:

e.g. the defineLink("LinkToSetFocusForVariable", "Guide/MenuNeeds*/*/Ensure*/Has*/SetFocusForVariable*") works fine on the first import, but the import code replaces the SetFocusForVariable widget with "REM FCL Guide MenuNeedsDefaultFocus hook code", so that when the plugin is reimported again the defineLink() can't find the widget any more, and the automatic linking fails ... If you modify the link targets in such a way, you will either have to restore the original state before defining the links, or use manual linking for those widgets

Dirk

Nope. I assume you repeated them in the other post. Figured I was misunderstanding how to use it. Thanks for looking at this. Now I know how to proceed.

BobP.

So, using this import/Java routines, I could link to the CenteredDirectoryBrower OptionsMenu widget in the main SageTV STV? Assuming that the answer is yes, then how do I know which one to link to?

Currently, the "main" copy of it is in:
Configuration Wizard - Set Video Recording Dirs/MenuContainer/MenuItems/Add New Directory/... a few more levels .../CenteredDirectoryBrower

There are references to it in four other places, like:
StorageDeviceAdded/if false/... more levels .../CenteredDirectoryBrower

So, if I understand the JavaDoc correctly, could I just do something like this to link in CenteredDirectoryBrower from the main SageTV STV?
df_sageutils_Import_defineLink("MTDirectoryBrowser", "//CenteredDirectoryBrower")

The reason I ask is that the one that Sage considers to be the "main" one does not remain static, at any given time, it could be any of the five occurrences.

----------

Once I get that done, what do I put into my import to call the main CenteredDirectoryBrower OptionsMenu?

Hi aperry,

the answer is: it doesn't matter to which occurence you link to, they are actually all the same widget... The concept of "primary reference'" (bold) and "secondary reference" (italic) is just a display thing inside of Studio.

"//" can't be used at the beginning of a path expression. But more importantly: my advice is to not use the "//" shortcut for any paths into the STV, since it has to follow all possible paths between the widgets, and since everything is interlinked in the STV this will visit a huge amount of nodes and take very long ...

Instead, to save typing, use the "*" wildcard in path expressions: for widgets with only one child, you can just use the "*" :


For widgets with multiple children use as much of the widget name as is necessary to distinguish it from the other children:

So just pick the shortest path to the CenteredDirectoryBrowser and use this path in the defineLink() call ...


Not quite sure, what do you mean by "call the OptionsMenu" ?


Dirk

What I mean is that assuming I put in something like:

df_sageutils_Import_defineLink("MTDirectoryBrowser", "/path/CenteredDirectoryBrower")

Inside my import, do I then just create an options menu item called "MTDirectoryBrowser"? If not, what do I put in my import so that once it gets imported, the CenteredDirectoryBrower gets called the way I would expect?

Thanks!

Hi,
I wrote this in a seperate post, but no one answered, maybe you can help, since you already did thiss with DeleteWidgetTree.

I am trying to do some cleanup after I broke some child parent relationship, and clean house.
I am trying to do RemoveWidget but it fails with the following error:


Do you have any ideas?
I need to do cleanup, I could also not break the parent but it wont delete it there either.

In your import, make the item and the action tree as normal, including setting up the variables required for the browser but add a text action as a placeholder:
"REM CenteredDirectoryBrowser to me", then in the actions after this one you can use the result of the browser...

In the import code, link the CenteredDirectoryBrowser to the imported text action

I am not sure but I think you need to call the Api with a UI context when you perform widget AP calls...

Thanks Nielm, that did the trick.

Where can I find out the rules about the different context, and when to use them?

Hi aperry,

you just have to create a dummy widget (type doesn't matter) with the name "MTDirectoryBrowser" at exactly the place where you want the "CenteredDirectoryBrower' widget to appear. As Niel said, you first have to set up the variables used by the browser. It would look like:

Don't forget to call df_sageutils_Import_linkWidgets() at some point in your import code.

Important: I discovered that linkWidgets() did not maintain the position of the link within the parent. Since the above code will not work if the position is not maintained, please download the current version 1.5 of the import library where this issue has been fixed.

Dirk

You had previously mentioned to avoid using the // notation. However, can't it get used with little to no impact once you get into a structure like this:

In other words, if I put in "Menu/Thing2//ThingIWant", that in theory shouldn't be any slower than if I spelled it out, correct? As I understand it, there is only one path to get to "ThingIWant" once I get to "Thing2" in the path, right?

This would be especially useful in a situation like what I have where there are 4 or 5 variables set before calling the CenteredDirectoryBrower, so if I could skip most of those variable setups for specifying my destination widget path, that would make it easier for me.