Hello everyone, so I am creating a menu, that has a submenu, the submenu, changes depending on the selected menu main item selected, so for example, if you select "games" , the submenu will show listed games, if you select "work, the submenu will change and show work related apps, etc, my problem is that I am not sure how to achieve this, as using:
seems to be not to efficient, because every time an item is selected from main menu, I'd have to deactivate every single other submenu.ini, is there any way to have like a floating variable that gets assigned when you select an item with the "LeftMouseUpAction" or something? anyt ideas are much appreciated, thank you!
seems to be not to efficient, because every time an item is selected from main menu, I'd have to deactivate every single other submenu.ini, is there any way to have like a floating variable that gets assigned when you select an item with the "LeftMouseUpAction" or something?
Please post the code you have so far. Otherwise it is extremely hard to describe what should you do.
what i am having issues with, is finding a way to hold the submenu items, and deactivate them and activate them as needed depending on the selected main menu icon, one way would be to put each submenu on a different .ini file, and activate them when the corresponding main menu icon is pressed, but then how to deactivate them as another main menu icon is pressed?
By using the Group=GroupName | GroupName2 | GroupName3
The rub is that toggling Group can get messy fast with toggle being sort of indiscriminate.
However, there is !ToggleConfig bang and it can be utilised by this hierarchy method: Skins\Config\, Skins\Config2\. With each config having subfolders with your groups (not a literal reference for group - not Group), and the subfolders would have each skin in them for the associated set of menu items each.
Another way is !ActivateConfig / !DeactivateConfig
And... another way is using a control or parent Measure with either using !SetOption to change the parent's Group and having DynamicVariables=1 set in the parent and children - or alternatively !WriteKeyValue depending on how your folder hierarchy is set up.
So !Bang !Bang !Bang - just possible methods depending on your experimentation successes.
Apologies for not disseminating the code with specific examples, but with this many possibilities, your testing is likely more effective than my giving examples.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
wolfnuka wrote: ↑January 13th, 2020, 10:04 pm
sure, no problem:
what i am having issues with, is finding a way to hold the submenu items, and deactivate them and activate them as needed depending on the selected main menu icon, one way would be to put each submenu on a different .ini file, and activate them when the corresponding main menu icon is pressed, but then how to deactivate them as another main menu icon is pressed?
I'm sorry, but to be honest I don't really understand the problem. There are bangs for both: activating (already used by you) and deactivating skins. Use them with no fear.
So, there are even more possibilities, in my opinion:
Create so many .ini skin files as many submenus do you need. Place all these files into one single config (folder), in this case let's say a folder named ULTIMATE-SIDEBAR\GAMING-SUBMENUS. So here you should have the GAMING-MENU.ini (already existing, based on the posted code), PROGRAMS-MENU.ini, DOCUMENTS-MENU.ini and so on. This ensures you that only one single of them can be loaded at a time. In such cases if you try to load another one, the previously loaded skin is unloaded, being replaced by the just loaded skin. In this case you have to load the appropriate skin when you're clicking the appropriate meter, [Image1] or whatever. Just take care not to have the main skin's .ini file into the same folder as the skins of submenu, because if you do have it, when you try loading a submenu, the main skin is unloaded.
Create the skins of submenus onto different folders, let's say the GAMING-MENU.ini into a Gaming, PROGRAMS-MENU.ini into Program and DOCUMENTS-MENU.iniinto a Documents subfolder of ULTIMATE-SIDEBAR config. Now you can load any of these skins by a !ActivateConfig bang and can unload all others by a !DeactivateConfig. For instance the LeftMouseUpAction option of the [Image1] meter would be in this case:
This procedure has a disadvantage: you have to add so many !DeactivateConfig bangs as many skins you have (less one in fact), but at least if you're using the skin normally only one of those skins is loaded at a time (because if anytime you load another one by clicking the appropriate menu, the previously loaded one is unloaded). This will give error messages in the log, whenever are you clicking a menu. This makes me to tell that the first procedure, described above is better, because it avoids those errors.
Finally a third option is to not create further skin files (further .ini files), but add the elements of the submenus into the code of the main skin. Not an impossible procedure. me personally at least probably would prefer this one. The disadvantage is that in this case the length of the skin increases quite enough, having to add quite many further meters and probably a few measures as well, to the code.
If you can't deal with all this, please pack the root config you have so far (ULTIMATE-SIDEBAR) and upload the package. It is extremely hard for anyone to help further if we don't have all needed files, resources and so on.
ADDITIONAL TIP: !Rainmeter... is a deprecated bang prefix, you should not use it. Remove all its occurrences from the whole code (see it is missing from the LeftMouseUpAction posted by me above).
balala wrote: ↑January 14th, 2020, 4:48 pm
I'm sorry, but to be honest I don't really understand the problem. There are bangs for both: activating (already used by you) and deactivating skins. Use them with no fear.
So, there are even more possibilities, in my opinion:
Create so many .ini skin files as many submenus do you need. Place all these files into one single config (folder), in this case let's say a folder named ULTIMATE-SIDEBAR\GAMING-SUBMENUS. So here you should have the GAMING-MENU.ini (already existing, based on the posted code), PROGRAMS-MENU.ini, DOCUMENTS-MENU.ini and so on. This ensures you that only one single of them can be loaded at a time. In such cases if you try to load another one, the previously loaded skin is unloaded, being replaced by the just loaded skin. In this case you have to load the appropriate skin when you're clicking the appropriate meter, [Image1] or whatever. Just take care not to have the main skin's .ini file into the same folder as the skins of submenu, because if you do have it, when you try loading a submenu, the main skin is unloaded.
Create the skins of submenus onto different folders, let's say the GAMING-MENU.ini into a Gaming, PROGRAMS-MENU.ini into Program and DOCUMENTS-MENU.iniinto a Documents subfolder of ULTIMATE-SIDEBAR config. Now you can load any of these skins by a !ActivateConfig bang and can unload all others by a !DeactivateConfig. For instance the LeftMouseUpAction option of the [Image1] meter would be in this case:
This procedure has a disadvantage: you have to add so many !DeactivateConfig bangs as many skins you have (less one in fact), but at least if you're using the skin normally only one of those skins is loaded at a time (because if anytime you load another one by clicking the appropriate menu, the previously loaded one is unloaded). This will give error messages in the log, whenever are you clicking a menu. This makes me to tell that the first procedure, described above is better, because it avoids those errors.
Finally a third option is to not create further skin files (further .ini files), but add the elements of the submenus into the code of the main skin. Not an impossible procedure. me personally at least probably would prefer this one. The disadvantage is that in this case the length of the skin increases quite enough, having to add quite many further meters and probably a few measures as well, to the code.
If you can't deal with all this, please pack the root config you have so far (ULTIMATE-SIDEBAR) and upload the package. It is extremely hard for anyone to help further if we don't have all needed files, resources and so on.
ADDITIONAL TIP: !Rainmeter... is a deprecated bang prefix, you should not use it. Remove all its occurrences from the whole code (see it is missing from the LeftMouseUpAction posted by me above).
This 'variant' method is actually quite tidy, and reduces the amount of repetitive code needed to switch between menus.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.
Mor3bane wrote: ↑January 14th, 2020, 9:44 pm
I referred literally to 'variant' as in multiple .ini in a folder resulting in each being a variant of the other as the result.
Oh, yes, in this case yes, it does "reduce the amount of repetitive code", as you said.
There are many ways to be different - there is only one way to be yourself - be amazing at it
The law of averages says what it means; even if you get everything right, you will get something wrong. Therefore; self managing error trapping initiates another set of averages - amongst the errors, some of them will not be errors, instead those instances will appear to be "luck". One cannot complain of the 'appearance' of 'infinite regress of causation', even if it does not have a predictable pattern, only that it requires luck to achieve.