A way to check what menu referenced code is running under?

[evilpenguin]

Is there a built in way to check what menu referenced code is running under? For example, if i'm in the SageRecordings w/ Optional Preview & AutoCategories menu I want some referenced code to act one way, but if i'm under the MediaFileList I want it to act a different way.

[PLUCKYHD]

Originally Posted by evilpenguin

Is there a built in way to check what menu referenced code is running under? For example, if i'm in the SageRecordings w/ Optional Preview & AutoCategories menu I want some referenced code to act one way, but if i'm under the MediaFileList I want it to act a different way.

Yup I do this in diamond all the time. Look at the widget API. I call exactly what you want like so.

GetWidgetName(GetCurrentMenuWidget())

That will get you the current name of the current menu in use. That returns the text as so "SageRecordings w/ Optional Preview & AutoCategories" or you can be safer and do it using the WidgetSymbol instead of the name so if the name changes you are still okay.

GetWidgetSymbol(GetCurrentMenuWidget())

Which will return the symbol name,

cheers

[GKusnick]

While Plucky's suggestion will work, I'd argue that it's not good design to make the referenced code's behavior dependent on the identity of the referencing menu. This would be analogous to making a Java method behave differently depending on the name of the calling class. The right way to do it in Java would be to pass in a parameter to the method specifying which behavior to use. Then it's up to the caller to say explicitly what it wants, instead of leaving it up to the method to sneak a peek at the caller and guess what it wants.

The same sort of discipline is even more important in widget code, where formal function definitions don't exist and the temptation to produce incomprehensible spaghetti code is much greater. If your shared code can do its job more than one way, then pass in a variable saying explicitly which way you want it done, and document that requirement in a comment at the entry point to the shared code. Take seriously the encapsulation of shared code and the proper division of labor between caller and callee by making everything explicit at the point of interface, instead of burying hidden contextual dependencies deep inside the shared code.

[PLUCKYHD]

Originally Posted by GKusnick

While Plucky's suggestion will work, I'd argue that it's not good design to make the referenced code's behavior dependent on the identity of the referencing menu. This would be analogous to making a Java method behave differently depending on the name of the calling class. The right way to do it in Java would be to pass in a parameter to the method specifying which behavior to use. Then it's up to the caller to say explicitly what it wants, instead of leaving it up to the method to sneak a peek at the caller and guess what it wants.

As far as I know EP is not coding Java but strictly in studio and I see no reason or wrong with using the Widget API for this use case especially for a Studio only coding addin (which I think he is doing). Yes you could go pass an attribute at every menu to get what you want passed but that is overkill and the widget api I believe was created to be used. I don't pretend to know everything about coding but I don't think it is bad design within studio and actually the only way to get the current menu symbol/name within studio short of creating an attribute that gets set at every menu.

While it gets buried and may become "spaghetti code" to me putting comments in studio is even more spaghettie code. If there was a comment widget it would make more since but to me there really isn't much of a way to avoid some spaghettie type code within studio.

[GKusnick]

The fact that Studio allows a looser coding style doesn't make it a good idea to practice that style. And with all due respect, Plucky, the fact that you don't see a problem doesn't mean there isn't one. It was exactly this sort of stylistic abuse -- gotos, global variables, hidden dependencies, and the like -- that drove the evolution of programming languages from the Fortran-like languages of the 1950s to the Algol-like languages of the 60s and 70s, with their modules, encapsulation, explicit function parameters, and so on.

If we don't want to repeat the errors of the past then it behooves us to learn those lessons and adopt a coding style -- even in Studio -- that approximates as closely as possible the modular, disciplined approach of Algol and its successors rather than just letting it all hang out Fortran-fashion.

To make it more concrete, let's say you have some shared code that can display information in a couple of different ways. Sometimes you want a list view, other times you want a grid view. You could do it as you suggested:

If GetWidgetSymbol(GetCurrentMenuWidget())
  > "GFDHF-12345"
    (widgets for list view)
  > "MNBMN-67890"
    (widgets for grid view)

Or you could do something like this instead:

"REM Display list view or grid view depending on the value of ViewStyle."
  If ViewStyle
    > "List"
      (widgets for list view)
    > "Grid"
      (widgets for grid view)

Of course you're free to code however you want. But I think you'd have a tough time arguing that the first example is somehow clearer or better or a more appropriate use of Studio capabilities than the second.

[jaminben]

I'll poke my nose in here and go with Plucky on this one as I'm pretty sure this is how Sage do it themselves when searching for or linking to/from menu items.... e.g when returning to a menu after playback has finished from within the MediaPlayer OSD.

Of course take what I say with a pinch of salt as Greg (and Plucky) have light years more expirence than myself

[PLUCKYHD]

Originally Posted by GKusnick

If GetWidgetSymbol(GetCurrentMenuWidget())
  > "GFDHF-12345"
    (widgets for list view)
  > "MNBMN-67890"
    (widgets for grid view)

Or you could do something like this instead:

"REM Display list view or grid view depending on the value of ViewStyle."
  If ViewStyle
    > "List"
      (widgets for list view)
    > "Grid"
      (widgets for grid view)

Of course you're free to code however you want. But I think you'd have a tough time arguing that the first example is somehow clearer or better or a more appropriate use of Studio capabilities than the second.

How is the first example not clear Given you know the api you are doing the same thing? A simple Comment line gives you the same explanation.

"REM Get The current menu name and perform action needec"
If GetWidgetName(GetCurrentMenuWidget())
  > "VideoList"
    (widgets for videolist)
  > "SageRecordings w/ Optional Preview & AutoCategories"
    (widgets recordings)

I would argue in fact that is clearer to me as if you are setting attributes for one you have to make sure you add your attribute to every menu item you want to use and for to another code looker has to go to each menu item and find that attribute to figure out what is calling our what. Where as using the widget api you are explicitly calling out the menu widgets name or symbol which is easily found by anyone. Granted you could search for the attribute widget but I don't see how that is any clearer.

Also not trying to argue just discuss

[GKusnick]

The most important difference between the two examples is that in the first case the shared code is making assumptions about who's calling it and what they want. It not a subroutine's job to make that sort of assumption. It should just provide a well-documented service and let callers decide for themselves which options they want. That's what the second example is meant to convey. All the knowledge about which option to invoke is communicated explicitly through the ViewStyle parameter, rather than implicitly by calling context. Again, this is exactly why function parameters were invented, to allow clean division of labor between caller and callee, so the callee doesn't have to make any assumptions about who's calling it.

As a secondary point, I'd also argue that discriminating based on menu name is extremely bad form. Suppose down the road somebody makes some changes to that menu and decides to rename it since the old name no longer describes its function adequately. Menu names are supposed to be like comments; they communicate something to the human reader but aren't meant to have programmatic meaning. By breaking that rule, you've created a booby trap that will blow up unexpectedly on somebody who's unaware that the menu name is embedded elsewhere in the code and must not be changed.

[PLUCKYHD]

Originally Posted by GKusnick

As a secondary point, I'd also argue that discriminating based on menu name is extremely bad form. Suppose down the road somebody makes some changes to that menu and decides to rename it since the old name no longer describes its function adequately. Menu names are supposed to be like comments; they communicate something to the human reader but aren't meant to have programmatic meaning. By breaking that rule, you've created a booby trap that will blow up unexpectedly on somebody who's unaware that the menu name is embedded elsewhere in the code and must not be changed.

That is why I also suggested the Symbol call since that will not change even if the name changes, I also assumed he was calling default menu's which won't change much or shouldn't.

I agree with your above statement in general I just don't think allot of those concepts pass on in Studio. Allot of the reason is like Ben pointed out most devs that are new will look at the default and copy how it is done there. I didn't search myself but Ben says that call is used so most will use that as an example.

In the end studio is an odd beast in my opinion while it does function well somethings are allot different then in most sceneraios and I always code in studio which ever way is going to put the least amount of code into studio and try to do most of it in java.

[GKusnick]

Originally Posted by PLUCKYHD

Allot of the reason is like Ben pointed out most devs that are new will look at the default and copy how it is done there.

That may well be true but that needn't stop us from encouraging newbies to develop better coding habits.

[PLUCKYHD]

Originally Posted by GKusnick

That may well be true but that needn't stop us from encouraging newbies to develop better coding habits.

Fair enough

[Opus4]

Originally Posted by jaminben

I'll poke my nose in here and go with Plucky on this one as I'm pretty sure this is how Sage do it themselves when searching for or linking to/from menu items.... e.g when returning to a menu after playback has finished from within the MediaPlayer OSD.

Of course take what I say with a pinch of salt as Greg (and Plucky) have light years more expirence than myself

No, this isn't really how the developers at SageTV do it. As one of the developers, I'll go with Greg's suggestion. Just because Studio doesn't have a way to set up well defined functions, doesn't mean you can't & shouldn't approximate it when using shared code. And, before someone points out a bad example in the default STV - I don't claim coding perfection, but there are plenty of cases where I use a REM statement as the entry point to shared code with the variables to be used named & explained.

Returning to a menu after playback ends really doesn't have much to do with this discussion. It returns to the previous menu based on what the menu history contains and whether that matches a global variable that was set when playback started. While it does check which menu to return to, it does not do so by hard-coding any menu IDs when playback starts nor when it ends and then comparing them. The only hard coded menu jumps after playback ends is when the previous menu isn't where playback started, in which case it decides what to do based on the media type, not the ID of some menu.

When I have shared code that is to perform differently based on some sort of context, I do not code in a set of conditionals/branches that check what menu you are on (at least I don't remember ever doing so); instead, I use variable(s) to tag what different behavior is to be performed. If the code normally behaves one way, then the variable can assume a default value (usually none because the variable isn't defined for the original/default setting & I don't want to have to go back & add it everywhere) and only needs to be set in the places where the behavior needs to change.

I'll admit that I don't always add a comment for the behavior-changing variable, but I should, if for no other reason than it would make my life easier the next time I need to update/use that code. And, while there is no comment widget type, using an action widget with a string that starts "REM <insert descriptive comment here>" is the generally recognized way to add a comment & is what the Studio manual suggests.


Go with the better programming style -- it may take longer when first writing the code, but it simplifies reuse and maintenance of the code later.

- Andy

[PLUCKYHD]

Originally Posted by Opus4

And, while there is no comment widget type,

Use some of that pull and get use one pretty please To me using "REM yadada" in a action widget just seems off. If we had a widget type of comments it would be much cleaner and probably get better coding out of all us for that matter. To me the REM method just seems messy and hard to follow. If we had a comment widget it would be easy to find them and locate comments.

Also while we on the subject a way to comment code out would be nice as well I know you could just put a false evaluation or leave it yellow as not part of the chain just thought I would through that at there as well

cheers