Author |
Message |
02/05/2019 20:29:56
|
#1
|
dsap4004
Joined: Apr 26, 2019
Messages: 21
Offline
|
Is there a jog menu item or at least a callback for if the select button is held vs the single fire option? Currently holding down select causes a boolean or callback menu item to toggle on and then toggle off again about half a second later. This is using the rotary encoder setup with the button built into it. This is not really an issue as long as you press the button and let go pretty quickly.
|
|
|
03/05/2019 07:07:07
|
#2
|
davetcc
Joined: Jan 19, 2019
Messages: 686
Offline
|
To be honest, the functionality on the select button being held has never been properly defined so far, as I've not really needed it on my projects (amplifier, test apparatus).
I had a few thoughts, the first being that on select being held, the menu would go back one level.
I'd be glad to take feedback on options for that. If the functionality is simple, it could probably be incorporated into 1.3.1 or 1.3.2. Longer term, I think it would need to be configurable with a few ready-made options.
|
|
|
03/05/2019 13:42:03
|
#3
|
dsap4004
Joined: Apr 26, 2019
Messages: 21
Offline
|
Jog is terminology used in VFD or variable frequency drives in factory automation systems and is typically assigned to a button that runs the motor in one direction when pressed and turns the motor off when not pressed. In a motor jog situation you don't want to have to press a button twice as you have less control. I figured if the only button available is on the rotary encoder and you have an exclusive call back menu item maybe there would be an option for button push action type. Something like execute on press or execute on release or extra callbacks for multi-click and even callbacks that run only while held for the jog situation. Doing it that way you can create a menu system more people are comfortable with. TIf they see a shiny button, they expect a jog option, they press and let go the and motor stays on, they panic.
Just so you know, I'm not trying to sound demanding. I feel like I'm the only one on here suggesting things at the moment. The current menu system will work with my project and I'm just assigning jog to other buttons instead of the menu. Just making sure I'm not missing options that are already in the library since I did see a held variable in there somewhere but it didn't look like it was being used.
|
|
|
03/05/2019 15:45:33
|
#4
|
davetcc
Joined: Jan 19, 2019
Messages: 686
Offline
|
To be honest, you're one of the early adopters and the docs are not completely finished yet, so it's fine to ask questions / find that functionality is still missing.
This is a bug that I've not noticed. The key is actually not repeating, but as I'd not mapped long press to anything, it came through the same channel. This is such a small fix and I'll fix in 1.3.1.
However, I see what you mean now. Yes, there is something close to what you want, there is an ActionMenuItem type. This just fires a callback on selection and nothing more. The designer UI adds these.
Once you get 1.3.1, nothing should trigger twice no matter how long you hold down the button.
|
|
|
03/05/2019 16:04:09
|
#5
|
dsap4004
Joined: Apr 26, 2019
Messages: 21
Offline
|
Yeah I couldn't remember the name of it at the time. Having different button press functionality for that action menu item would be amazing. Also since the boolean menu type can be used in this way it would also benefit from the ability to choose how the select button triggers the callback. Imagine a boolean menu where you can enter the two string options and choose how the select button works. If you leave the two string options the same and the callback fires on change then you don't even need the action type anymore.
I know features can get out of control pretty quickly as there are so many things you can do with an interface like this and maybe it's not as intuitive for people who are building a menu to use the boolean type as an action type but that's how I saw it right off the bat.
Thanks for taking my input and running with it. I'm hoping to upgrade to the new version when it comes out as it will greatly improve the usability of the system. My menu has 130 items in it since I'm setting timers for a bunch of devices. Timer type anyone? lol
|
|
|
03/05/2019 16:45:17
|
#6
|
davetcc
Joined: Jan 19, 2019
Messages: 686
Offline
|
Scheduled tasks are supported by the underlying IoAbstraction, which underpins TcMenu. Supports both one shot and repeat triggering. In fact, it's how tcmenu does the button management, rendering and serial / ethernet remote.
Up to a few millis can be scheduled at the microsecond level.
Up to about a minute can be scheduled at millisecond level.
Up to about an hour can be scheduled at the second level.
Take a look at the taskManager sketch in the IoAbstraction library, it shows you how to create and use tasks. Should be easy to modify menu from those tasks. However, bear in mind that the accuracy of the scheduling depends on having no long running tasks.
|
|
|
03/05/2019 18:39:04
|
#7
|
dsap4004
Joined: Apr 26, 2019
Messages: 21
Offline
|
Ioabstraction for scheduling. Good to know.
|
|
|
07/05/2019 10:39:45
|
#8
|
davetcc
Joined: Jan 19, 2019
Messages: 686
Offline
|
I had TcMenu all ready for release yesterday in the afternoon, including most of the fixes that we’d discussed, but at the last moment I found a showstopper bug in it with memory corruption.
Already tracked it down to one function, but I’m a bit time limited this week with work at one of my clients. So I’d say best case later in the week.
One of the big changes that Should be almost silent to you, is that ESP boards are now fully supported and have their own platform in the creator. There is a full example for the esp8266 including the first pass at WiFi remote control.
|
|
|
08/05/2019 17:50:24
|
#9
|
dsap4004
Joined: Apr 26, 2019
Messages: 21
Offline
|
Can't wait to use it. Especially the back functionality not going to the top of the tree and holding select only firing callback once. It would be nice to have the eeprom settings working on ESP32 as my implementation is buggy at the moment. I run multiple loops using FreeRTOS and things like SERIAL and EEPROM don't seem to like it. Calling those items in the menu callback functions is hit or miss. If I run attempt a Serial.print inside a callback it usually locks the callback up. or if there is a for loop inside of a callback and I want to check the iteration with a Serial.print the loop breaks and just iterates forever hanging up the program. Still not sure if that is my fault for using tasks but hard to debug without serial functionality. Probably a topic for another thread.
|
|
|
08/05/2019 21:18:21
|
#10
|
davetcc
Joined: Jan 19, 2019
Messages: 686
Offline
|
Just to let you know 1.3.1 has just been released for Windows (MacOS later this week).
There is a new example for ESP8266 that is setup for an OLED display. This shows usage of the ESP8266 EEPROM and WiFi.
The two click problem is fixed as well in this new version.
|
|
|
17/09/2021 01:07:59
|
#11
|
patebeng
Joined: Sep 17, 2021
Messages: 5
Offline
|
removed
|
|
|
|