Message |
|
|
 |
|
|
 |
|
Very soon we'll have an early access version of tcMenu Designer on the Window store, written natively for Universal Windows (Win10).
If you're using Windows 7 or 8, for at least another year we'll keep the old designer viable.
Link will follow shortly along with some basic instructions to get started.
|
 |
|
Hi there,
The safest option in the current version is probably to subclass the submenu item (option 3 basically). Let me know if that works for you, if not I'll have to look into the possibility of other options. Certainly don't remove const on any of the PROGMEM definitions, you'll get unexpected results on many processors.
The longer-term solution may look more like a runtime menu item as that uses a callback mechanism to get the name, so you could set name at will when requested. However, right now it wouldn't work because it's not a sub-menu type and MenuManager object expects submenu's to be of a specific type SubMenuItem. Going forward a subclass of RuntimeMenuItem may need to be able to fulfill the same contract. Maybe in a future version, I could create a new interface called something like IMenuWithChildren and then make a version of RuntimeMenuItem that implemented it (maybe RuntimeSubMenuItem) along with SubMenuItem.
So in summary, my vote's for option 3 right now if that's workable.
|
 |
|
Hi there,
Yes, we plan to release it very soon! We are just doing a final fix and more testing of a new version of the designer on Windows, a complete re-write of the original that's way easier to release and support. Designer for MacOS is nearing the end of development.
In terms of the embedded libraries:
They are already available on the master branch, you could test them now.
In terms of the designer UI:
The windows version is probably a week or two away. The mac version is a little behind. Once released, both of these will be hosted in the Windows / Mac app stores. They will be native apps on each platform written using UWP for Windows, Xamarin.mac for MacOS. The embedded libraries will be installed from Arduino's library manager instead of by the App starting in 1.4.
The original Java UI will be built one last time for users of Windows 7, we'll keep that viable for at least another 12 months.
In terms of embedCONTROL remote control UI
This will be released for Windows / Xbox around the same time as the designer. It will be available via the Windows Store. The original example control UI will remain for users of Windows 7.
Following this will be Apple devices, a simple design of the remote control will be written for MacOS first, followed immediately by one for iPhone and iPad.
Android timeframes are yet to be determined.
|
 |
|
|
 |
|
Ah, the header string for the show function is expected to be in program memory! I'll make sure the docs make that clearer.
Just declare it as in progmem, see in the nokia 5110 example.
// declare as follows
const char warningPgm[] PROGMEM = "Warning!";
// and then use it as follow
dlg->show(warningPgm, true);
You may even get away with the Arduino F function, but I've never tried that..
|
 |
|
I think you need to "declare" the function, because you're using it before it's fully "implemented". The fix for this is usually to declare the function before it's defined, see below.
Can you try putting the following line before the usage of onDialogFinished (IE near the top of the file, just after includes):
void onDialogFinished(ButtonType btnPressed, void* /*userdata*/);
|
 |
|
Many thanks for the feedback. Glad that's sorted.
If you do get hit by the submenu in the initial position problem, there's a fix on master of the library.
Dave.
|
 |
|
Many thanks for providing this implementation. I'll take a look at it soon to try and integrate it into the library.
|
 |
|
Still one problem: clicking on the submenus just leads to the first menu item...
We did recently fix an issue in 1.3.6 where if the first item in a menu was a submenu, it presented that submenu rather than the main menu. Is that the issue you have? If so, this is already fixed on master, and you could try that to see if it works for you. It will be released soon.
Otherwise, if that is not the issue, please could you share your designer project structure, so we can take a look. If you could create the simplest structure that recreates the issue, that would be great.
|
 |
|
Good idea, I don't want to leave behind the Uno. It's used by a lot of people. I test every single release on Uno with serial support and Liquidcrystal. If this library has memory characteristics closer to that end of the spectrum, then this should work. For every release, we have a base line for that of about 28K. If it increases from there, I try and work out why and get the memory back down.
An issue has been raised against the tcMenu main project to create a plugin for that library. It will now be after the 1.4.0 release, which shouldn't be that far away. In the meantime, you could either test on a larger board, or use the Liquidcrystal library that has lower memory requirements.
https://github.com/davetcc/tcMenu/issues/70
|
 |
|
This is odd behaviour. We have a SAMD board but we are using the rotary encoder connected via an IO expander due to a lack of pins available.
It seems to be like the encoder or button is unstable for some reason, but I will try connecting an encoder directly to the MKR board I have and reply once I've managed to test it. It's not the Adafruit board you mentioned, but is a SAMD based Arduino MKR board.
Could you let me know what pins you've wired the encoder and button to and I'll try and recreate something as close as I can?
Could you check that the pins you've used for the switch and encoder don't conflict with any hardware serial devices such as your display, or anything else that may be inbuilt? We've seen this cause major instability a few times now.
|
 |
|
Unfortunately, there's probably not enough space to use any kind of U8G2 display along with TcMenu on such a small board.
There's a couple of things you could try, mainly removing any use of i2c and spi that is not needed. Remove any libraries that you could live without. Other than that, there's not much more that can be done.
The smallest 8-bit board I recommend for using with graphical displays (IE other than LiquidCrystal) is the MEGA.
With ESP and MKR boards being cheaper than the AVR boards, we recommend using either MEGA or a 32-bit board for anything graphical.
EDIT: We test Uno in our test cases with an i2c LCD backpack and up-down buttons. We keep the menu small and even manage to fit serial remote capability in, but it's very tight, around 28K used. For Uno and similar boards, keep it small, use as little extra as possible
Thanks,
Dave.
|
 |
|
Sorry I've not had a chance to look over the sketch fully.
The way the EepromAuthenticatorManager works is that it initializes from EEPROM only if the magic key (you either provide or is defaulted) is in the ROM already. If it is not already in the ROM it defaults to 1234. It also stores 6 pairings with user name and UUID of remote connections there too, even if you are not using remote connectivity. You can lower this number if EEPROM storage is tight.
To change the pin / password, simply call changePin(newPin) on the EeepromAuthenticationManager. Usually, you'd do this from within a protected menu. Maybe create a text field to hold to replacement pin, and an action item to take the value and call changePin.
Also, in terms of all the code in loop doing timing, you know that taskManager is part of tcMenu, you can use that to schedule things to be done, once or at a repeated interval, take a look at the following:
https://www.thecoderscorner.com/products/arduino-libraries/io-abstraction/task-manager-scheduling-guide/
|
 |
|