OK… I been putting up with this for a while..but actually want to know if there is a reason for it to be this way or not. On menu screens (pretty much everyone)… when you create a menu item, you must select the screen to point it to…. but only on menu item creation. There is no way to edit the destination screen. You can only delete the entire menu item and replace it. Why is this? Is there no way to add a ‘change’ or ‘edit’ or ‘select’ next to the destination screen, that once you click on it, you can change where the menu item will point to? That little modification will make menu management like 60% more efficient. Especially if you are using a menu plugin which has a lot of settings... which in the current method, means that I have to redo all those changes when i create the replacement menu item, before deleting the old one. And even if I do change the pointing destination in the <> code section, the gui does not update to reflect the new destination (leading to a mismatch). Is there any reason for this to remain this way? I’m seriously asking...

Well, I'm designing a menu that doesn't allow childItems in the control panel, almost for that purpose. It's a bit of a challenge to be the iOS master and the Android master and the php master and the mysql master. There's a lot of juggling going on up there :) I'm not apologizing for any situation, but It's possible you're not aware that using an external childItems file is the cat's meow. I find it far easier than re-typing items into the control panel anyway. Consider this work flow: Designing your menu via Excel or other spreadsheet application, using 'columns' for your json keys and 'rows' for your json values. Easy to edit, search, replace, alter in any way. Then convert them to json and make the edits to create a custom childItem file, or you can use my spiffy Json childItem creator script in your self hosted panel to make it super easy. (Available for free at the BTMods marketplace) Once you've got your spreadsheet the way you want, create a childItem file with your preferred solution, and then just either include it in your app bundle, or put it on the net as a dataURL. Once you've tried it, you'll never create childItems in the control panel again. It also has the added advantage to allow you to easily recreate menus, quizzes, and other screens without having to retype everything. Just a thought. Cheers! -- Smug

hmmmmm. where do i get my hands on that excel->Jason magic wand? (EDIT:oh wait..i just saw that) so with that.. u manage everything by columns and rows? but i guess you still have to copy and paste item numbers from the cp so they match up right? not too bad i guess.

ha..its new too. i somehow missed the announcement

Well, you 'can' do that. I actually use 'loadScreenObject' a lot. You still need the plugin 'code' in your project, but it's kind of dynamically creating screen configurations, because I have a lot of locations that have unique data on them that need to be displayed on a map that are not always 'pre-known' (like, distance to a location will change as you move around). I'm almost ready to beta my Android version of the location menu plugin… And I don't accept childItems; you'll be forced to learn 'loadScreenObject' (I'm writing a tutorial so I can ward off most questions at the start)… If you peek at this screen shot of my Android device: https://dl.dropboxusercontent.com/u/115208762/slm_android.png all of the menu selections, and the screens that they transition to, are created 'on the fly' by using loadScreenObject, rather than requiring an itemId for each and every screen. It was a bit of a challenge to wrap my head around it at first, but once the light bulb went on, I never looked back. It's so much better, lol! Let me know if you have any questions. I'd be happy to convert you, lol! Cheers! -- Smug

Please put up the link to the magic tool.

https://buzztouchmods.com/market.php Look for my Json Converter script for Self Hosted. It's free. Cheers! -- Smug Oh, and for those not self hosted, Niraj pointed out a simple solution; Change sjcon.php to sjcon.html and double-click on it to launch it locally. It's javascript, so it should work just fine.

Yeah I agree with Smug.. Ive been using excel + a csv converter since I started using BT. It's just faster and practical. You can get a lot more done and changes take no time. Plus with the addition of being able to copy and paste that to the new control panel. There are converters online that I've posted in the past.

ok..talk me though the workflow on this. I can use this to setup menu items …but not the items themselves? @SmugWimp (looking at the sample data)… - 1a. You have to first create these screens in the CP, then copy over their item type and item ID? (the rest can be made up in the xls?) or? - 1b. did you make these up in xls (but knew the correct naming format for the plugin itemTypes), and when it was converted, it automatically created the screens in the CP for those destinations? ok..I just read this in your original reply "Once you've got your spreadsheet the way you want, create a childItem file with your preferred solution, and then just either include it in your app bundle, or put it on the net as a dataURL. “ - What other solutions are there away from “+add Screen” in the cp? hmm..so basically with the new <>code component in the cp…you essentially can begin to transition off of CP development…and move more to dataURL dev, where you just link to the relevant files (with obvious pros and cons)…but a lot more modular dev for sure

It would depend on which method you're going to use. If you're going to use loadScreenWithId then yes, you'll need to create one or two screens in your project, determine the itemId, and use that in your spreadsheet file, and changing the other values to suit your design. With loadScreenObject, you're not using an itemId to identify a plugin. You're using the plugin's 'itemType', which is also (usually) the class name in both iOS and Android (such as "BT_screen_map"). Typically you would use this method if you're going to be creating a fairly large number of 'similar but not the same' screens, or if you want to dynamically create screens from a PHP/MySQL data source (via dataURL and php file) Too long to paste here (it loses the formatting anyway) I have a quickie example of the 'childItem' file for my upcoming location menu plugin. https://dl.dropboxusercontent.com/u/115208762/sampleChildItems.txt The childItem file uses 'loadScreenObject' to create the 'next' screen (when you tap the menu choice). You can see that loadScreenObject is basically 'a screen that contains information for two screens; the current and the next'; containing the screens complete json 'ScreenData' for itself and the next screen. It doesn't matter what 'kind' of screen you decide on, as long as you include all the pertinent json to adaquately configure the screen. Hopefully I can explain it better in a tutorial, but that won't be today, so do some searching, and chew on it a bit. I'm happy to help with questions. Cheers! -- Smug

Q's for @SmugWimp re The itemid field. Does it have to be a unique string for only this screen, or for the entire app? Are there max or min character lengths for the itemid? I am asking as: 1. You use "itemId":"02816" in the above example file. 2. Buzztouch uses "itemId":"0F79BE4D94C26D06CF1727B" when entered through the CP 3. Your Menu Image Advanced plugin page uses "itemId":"menu_1"

The itemId has to be unique to the app. "Typically", when a plugin is added to your control panel, a 24 character 'itemId' is randomly generated; there is no 'meaning' or correllation to anything. As long as it is unique, you're good. My itemId is usually generated from my database record numbers. But they can be anything random. If you're creating the screen dynamically via loadScreenObject, you're more concerned about the itemType than anything… ensuring you're feeding the right info to the right plugin. Whether the itemId is 1234 or 4321 isn't all that important (in loadScreenObject) as the 'itemType'. If you're calling for a BT_screen_map, you can't feed it childItems meant for a menu, or an HTML field. Now, if you're using 'loadScreenWithId', then you're not talking about randomly creating screens, you're talking about a 'specific' screen and it is requested via itemId, not itemType. In these cases, the itemId is still going to be unique throughout the app, and it will be 'tied together' with the app via itemId, not itemType. Cheers! -- Smug

Smugs doing good work for sure with that. But also, not all menus suffer from the problem Uelsimon lifted up. Some do, some don't. (My latest, for instance, doesn't have this problem). Any of my plugins you find that need to be updated for this, let me know.

Chris -- does that mean the other Menu plugins simply need a "quick" update to the PHP or HTML to allow for the initial rant? Should Ranter ;-) make a request on the BuzzTouch v3 bug report post?

Ranter probably should :)