Message |
|
Actually, I've chatted a long time user, and they had one internally. It was based directly on RuntimeMenuItem and I should have something working soon. Given this, and it's a very low-risk addition, we'll do it in a patch release.
We'll try and get it into the next designer release as well. Again it's low risk and only affects anyone who uses it.
|
|
|
Hi there,
At the moment this is not implemented in the core but we do plan to support it. Two options for right now:
* you could try locally modifying the EnumMenuItem to handle this for now, but the designer wouldn't be able to work with that item. However, you can add items into a menu yourself at runtime, a menu list is nothing more than a linked list (where each menu item has a next pointer).
* My favoured approach would be to implement it as a editable RuntimeMenuItem, these are quite new so the documentation is not great, but the reference implementations in RuntimeMenuItem.cpp/.h should point you in the right direction. Again as above, you'd just add this custom menu item into the linked list at the right place in code.
This may suffice for you in the immediate/short term, while we get around to this feature. You'll even see how to add extra menu items at runtime in the packaged esp8266 example.
As I said above, we have a plan to add it, as in the longer term we need it ourselves for a few projects. However, at the moment we are on a stability drive, the last two releases have introduced bugs onto some of the platforms, as there have been a few huge changes introduced (RTOS support, multi-core safe task manager). We need a couple of cycles where there are no new major features. But we'll add it to the 1.7 issues.
May I ask that you add an issue into https://github.com/davetcc/tcMenuLib/issues with the information about how you see it working, and I'll combine with our existing thoughts on it.
So for now, you could do as suggested above, and add a menu item yourself with my preference being a editable runtime menu item.
|
|
|
We now have instruction on how to run the designer on Linux, and these are confirmed to work by several users. Please see the tcMenu repository.
|
|
|
Hi there,
Thanks for using the library, and the compliment.
There's a couple of callbacks that you can use to determine when things have changed. But at the moment we don't have one for edit started. However, I think that would be easy to add, please add an issue in tcMenuLib https://github.com/davetcc/tcMenuLib and I'll try and do it in a patch release, as it shouldn't be much work.
What you can do now:
Every menu item supports a callback, you can set these in the designer, and the function gets called with each an every change, for an integer edit this could be a lot of times.
You can in addition to this, add a commit handler in menuMgr, this gets called once when editing stops:
void setItemCommittedHook([](int id) {
// do your commit code here.
});
I guess we could do something along the lines of:
void setItemEditStarting([](int id) {
// do your edit start code here.
});
|
|
|
I've tried this myself with Arduino IDE and it seems to remove the task manager files with the very latest version.
However, I've added back an empty TaskManager.cpp & a .h that just includes TaskManagerIO.h. This is probably the safe thing to do, and can be removed in the future once most people have had time to upgrade.
This should work with all versions of LibraryManager and all other IDEs/platforms too. I'll make a patch release for this soon.
|
|
|
That's a bit worrying though, it tends to suggest that existing users are going to hit this quite a bit.
Thanks for reporting this as we could start to see more cases of this.
We'll need to look at recreating this on a test machine.
|
|
|
It looks like you have an old version of IOAbstraction that still has TaskManager.h present. Can you check tcMenu and IOAbstraction libraries are fully up to date. Basically task manager was split out in the last release.
|
|
|
As of today, tcMenu Designer is in the Mac App Store.
https://apps.apple.com/gb/app/tcmenu-designer/id1527782002?mt=12
I'd be glad to get any feedback on it. It's a native Cocoa app that's based on the same generator as the Windows store generator; which has been around for a while. Please raise any issues here.
|
|
|
Hi there,
Good to know most things are working for you.
This sounds like a bug in the Adafruit_GFX renderer, please can you raise a bug report in the tcMenu project: https://github.com/davetcc/tcMenu
For the time being until we can fix it when you call give back display, set the font back to the default one. I think that will work as a temporary solution.
|
|
|
Sorry but I really don't understand this question. I'm assuming that you have a 16x2 LCD display, is this display connected to the Arduino over the i2c bus? Every DfRobot board I've seen so far has been a shield, and therefore uses direct pin connections that cannot be changed.
However, if you have an LCD display with an I2C backpack and the "LCD shield renderer for common i2c devices", then once you've changed the address of backpack (A0-A2 jumpers normally), you'd then set the equivalent address in tcMenu designer code generator, the property for this is "I2C Address". IE if you made A0 active, then the address would change from 0x20 to 0x21 for most backpacks.
|
|
|
Attachments should now be supported
|
|
|
Feel free to reach out again if you need more assistance getting started with this. I would be interested in how it works myself if you can get a prototype working, it may be an option that should be added to the core set.
|
|
|
I mean that in the TcMenuDesigner application -> Generate Code dialog, you'd turn off the generation of input facilities and then instead you'd just provide your own rotary encoder and select button function.
There are many implementations of RotaryEncoder (base class defined in SwitchInput.h) that you can take a look at, and then implement your own. I'd say the up down one would be the best starting point. RotaryEncoder is a really bad name for the class, it's really something more akin to Scrollable. The way tcMenu works is that the menu position is controlled by the encoder, and in edit mode, the values are chosen by the encoder. So if you implement that, you'll get everything out of the box.
For an example of what the default does, see MenuManager::initForEncoder and MenuManager::initForUpDownOk in tcMenu.cpp
Always set up the input last, basically after the setupMenu() has finished in your project sketch / main file.
|
|
|
Hi there, yes within reason you can manage the menu in any way that you wish.
Basically you could set the input facilities to none, or custom input in the designer and then implement the input by just using two switches. Switches is a core part of the libraries that make up tcMenu and handles buttons with event callbacks. Take a look at the button / switch examples in https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/.
Once you've got two switches working, you can decide what function of the button (press, long press, repeat etc) causes which function.
For this, you'll interact with menuMgr, the object that is in control of the menu. I would implement RotaryEncoder in a way that it works for one button, as you described above, in the base class, there is a maximum value and a current value, you would essentially just implement it to go up every time the button is pressed and then wrap. You could even make it so it can go up and down, but for example, down has to be held down to work as down, where a short press is select. Take a look at the UpDownEncoderButtons class in https://github.com/davetcc/IoAbstraction/blob/master/src/SwitchInput.cpp as a starting point for that.
What I'd do is start with a sketch that uses the standard 3 button arrangement, and then understand how it's configured in <projectName>_menu.cpp/h in your project, this will give you an idea how to implement and set up your own facilities. Never add any code in the <projectName>_menu files, as they are overwritten every cycle.
|
|
|
Firstly, the display remaining blank.
I think you are missing the u8g2 function to actually send the data to the display. These displays are buffered in memory, and only sent once all the rendering is done if you see what I mean. You need to call:
u8g2->sendBuffer();
Secondly, you don't need to do that timing loop in your function, tcMenu uses IoAbstraction library, and that has a task manager built in. Just start a task manager task for things that need to run on a schedule.
To schedule code to run every 200 millis until taskShouldRunAgain is false you'd call someTaskFunction once, then it woulld schedule itself until taskShouldRunAgain was false.
void someTaskFunction() {
// do your task
if(taskShouldRunAgain) taskManager.scheduleOnce(200, someTaskFunction);
}
To schedule something to repeat forever (or until cancelled)
auto taskId = taskManager.scheduleFixedRate(200, [] {
// do your task here
});
There's lots of documentation around this: https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/
|
|
|