I noticed that when you click on a feed item, display the Web page for it, then navigate back to the feed list, scroll down so that the selected list item is off the screen, then scroll back up again, the selected feed item row is blanked out. Anyone else experiencing this, or just me? I did download the app source again. It's happening with any feed item row I select. Cheers

Yes! I was wondering the same thing. It doesn't happen when going back to the home page, but if I click to link, then go back to home, then scroll down the original rss item will disappear until I refresh. Happens in simulator and on device with me.

@shenry. Thanks for verifying...I'm not sure if I should be glad I'm not the only one, or anxious that this gets fixed soon...trying to finish off my app, and this could be big boo-boo for users...the list refresh needs to be fixed :-) At least I got Scringo working, which is cool :-) Cheers

I'm actually using BTM: RSS feed plugin, but sounds like it's the same behavior.

@shenry. Oh, you mean you're using self-hosted and installed that there?

Hi all. Both RD simple RSS and BTmods RSS plugins are derivatives of the original BT_rss_screen. The "bug" you have pointed out is from the original code. The same issue happens with a 1.5 app from over a year ago, but no one has ever noticed it. My guess is that the "Row Select Style" in the RSS List Layout/Color section of the code is somehow overriding all other code for font, list, and row when "scrolling" is used. "Pull to refresh" brings it back. I will look this weekend to see if it is just a matter of sequence that the code launches. If it is more entailed, we may have to solicit the great David himself, or Kittsy, or Chris1, or ........ Any input is greatly appreciated.

Thanks Red Dog. That would be extremely helpful. Would you mind responding to this thread if you are able to fix?

@Red Dog. Thanks. Appeciate your work on this. We'll be your test subjects :-) Cheers

Hi Red Dog, "but no one has ever noticed it"???? see this: http://www.buzztouch.com/forum/thread.php?tid=8C7B38D258F32909BD078A9 Good luck!! Best Regards, Danny

@PSMDanny...nice one :-)

So ... This should also happen in non-RSS scenarios when the Menu plugin is used? That is what I understand when reading David's response to Danny on the above 1-year old link. -- Niraj

@Niraj. I'm using the Menu with Image plugin and tested, it doesn't seem to be happening there :-)

Thanks Danny. Totally missed that thread. David's answer does not give much hope.

Hmm - if I get some time this weekend to look at code I'll check it out. If David is right that the cell is trying to do too much, we could create a few different version of the custom cell, put them all in the plugin, and use an if/then check in the code to decide which custom cell to use for each row.

Interesting... This was the main reason I started building my own, that was driving me crazy. I haven't had a good chance to really hammer on the new one with actual feeds, have been playing with the layout mostly. Didn't notice it was happening yet. It would be totally gutting it - but just like the DAS Video parser/plugin here - most of the RSS samples I looked at use XIB's and custom cell view XIB's. Make you wonder if problems like this view recycling are why.... This is really a great case study on using XIB's vs coding. No way you could have that finite control over the table rows/heights and colors using an XIB unless you use the IB Editor. But with code you can change that stuff dynamically. This is where I stalled out building one - so many options trying to connect and control with the panel vs just editing the XIB which i find easier. On Androind it's a lot easier to mod the layout files. but you have to dupe the plugin to re-use it in an app if you want to customize the xib.... Keep us posted, maybe I won't shelve my RSS projects quite yet!

You can still modify elements from the nib file using code in the .m file. Not sure I understand. Can you give a specific example of an element on your nib file you're referring to?

I'm aware there's some functionality still, code knows no limitations! I just prefer to think of and use the IB as a WYSIWYG editor :)

If this is something that needs to be customized for each screen - I'd be happy to pay someone to fix mine. I use it for several screens, but they're all set up the same. For anyone wondering about the rss issue, here's a quick look: http://www.youtube.com/watch?v=plSk5VTxfls

I think we can make this work without it being a custom solution for each user or screen. I just need to find time to look at it. (Moving in a week and starting a new job)

Oh my! That video made me shudder! No way can any of us deliver such a "buggy" implementation to a Client. I wonder if the "modern" iOS can ... Oh we'll, it's already been said in the earlier comments. Yikes! Hurry, Chris! -- Niraj

@Niraj...yep...I keep delaying finishing my app...and keep finding bugs (3 different plugins so far and I'm using all 3 in my app)...like I said in another post, we need to have some standards & QA before putting code on the plugins market :-) I don't mind helping out doing some testing...I just can't deliver an app that is buggy...reflects badly on everyone :-) Especially, if we want to deliver full featured apps. Cheers

Well, there is QA testing that goes into the plugin development process. But bugs will happen, it's inevitable. Part of making apps on Buzztouch is taking some responsibility for the code. Clients are not just paying us for our ability to drag and drop. Still, I'll try to get this one resolved quickly. What are your other bugs?

@chris1. Not talking about this issue alone. And I wouldn't say it was a simple drag & drop :-) There are code changes (eg removing code to get points out of 100 for Quiz, or adding code for 3rd party add-ons like Scringo, etc), design elements (fonts, colors, images), data creation (HTML docs, custom RSS feeds, data gathering & custom information creation), etc. So, not a simple drag & drop (wish it was) :-) Thanks for working on this, and we all appreciate the extra effort. I've already contacted some of the plugin creators for other bugs and posted some in the forums :-) All I'm saying is maybe we need some testers to test plugins before they go on the general plugin market, and kill some of these bugs (rather than just a code review) before they affect a lot of people...and yes, I know bugs will still seep through and we can never be 100% bug free :-) And yes, I'm willing to be one of the test volunteers. Anyone else? Cheers

Sounds like a cool project you're doing. As it stands right now, all plugins must be fully tested by 2 other plugin developers. There isn't a good process for how those testers are selected - its up to the developer to find 2 people to test, which doesn't always happen easily. I have one plugin I haven't been able to submit because I haven't gotten 2 testers to try it out and respond to me. I know some ideas for how to improve the plugin market have been discussed by the Buzztouch team, but I don't know what those are as they haven't been made public.

@chris1. I wouldn't say my app is exceptional :-) I think most developers will probably be going through the say process to create apps if they want to compete with all the millions of apps already out there, especially with larger design/development teams :-) Cheers

Okay - finally had a few minutes to take a look at the code. Think I figured it out. In the Rd_simplerss.m file, look for the method called: - (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {...} In that method, about a third of the way down, is this line of code: [thisMenuItem setJsonVars:menuDict]; Comment that out and see what happens.

@chris1...cool, will try that out once I get home...was stuck in bad traffic and had to pull over to let the traffic die down :-) Long weekend (Monday a holiday) here...crazy. Cheers

Thanks Chris, are you saying to delete this: http://postimg.org/image/rzfrdwjud/

I think of comment out as this <!-- This is a comment -->

Yep - you can either delete it, or comment it out like so: //this is a comment Or in this case: //[thisMenuItem setJsonVars:menuDict];

Woohoo, Chris you need a tip jar. This is the second time in a week you saved the day for me. Now: http://www.youtube.com/watch?v=gLlRfXPcuvs&feature=youtube_gdata_player

no problem - glad to help! BTW - your video is marked as private

By the way, if anyone is wondering why this bug exists in this plugin and not in the Menu Image plugins, here's why: The line of code overwrites the configuration data for the item selected by creating it's own "dictionary" of json data. It probably should never have been in the original code ... and in fact, it's not in the menu plugins. This is also why the item selected is the only one that goes blank when coming back from the webpage. If you select a new row and come back, they are both blank as they both have been overwritten now. It will remain that way until the screen exits the memory and has to be reloaded. This happens when the app is refreshed, or when it is completely exited and re-opened.

Sorry about that, Video is public now.

just watched it - looking good Shenry!

Amazing ! Here I was driving home tonight from the desert thinking how I should approach this "bug." I was thinking that people much smarter than I have not attempted a fix, what chance do I have? And then I find out that Chris swooped in with two little "slash marks" and a whole lot of expertise and saved the day! Again! Thank you Chris. Not only did he squash that "bug," but he took the time to share what the code was doing and why it was causing the effect we were getting. Did he call me and say he could fix my plugin for a fee? No. (He should have) Well, I just purchased three more of his plugins to show my appreciation. Chris is a great example of the many people in this forum that help make the Buzztouch ecosystem a fantastic place to be. And yes Steve, I WILL be using you as a final tester before submitting my next plugin to the market ;-) You have a good eye.

Thanks for the support @Red Dog. And to think, 8 months ago I was opening up XCode for the first time and had no clue what a "method" even was! That's the beauty of this community though - and why what David has built is so brilliant.

@Chris1. Nice fix...you are now the official bug crusher :-) Bug Seeker, Bug Crusher...sounds like a fantasy movie in the making :-) LOL. However! Why am I now getting this error: http://postimg.org/image/5fppyajfn/ Should the variable be set to something? Is it null and that's why Xcode is complaining? I don't like seeing errors :-) @Red Dog. You're on. Glad to help in any way. Just waxing a little prose below: I think Buzztouch is awesome. What David has built is incredible. However, the heart of the whole system is the plugins. I've mentioned this before in another post, but I think as a group we need to start putting together some guidelines for both exposing options/features (via the control panel) and testing useability of plugins. If we take some examples from leaders, e.g. Steve Jobs, I think we really need to put more focus on our app users, e.g. if someone is using the Quiz in our app (say for a simulation of an exam) would they care about bonus points or would they be more concerned about how much they got out of 100%? If it was a game app then things might be different, but again that should be allowed for in exposing features and considering the useability of the plugin (I know that's an older plugin but I'm just taking that as an example). We can have a group discussion about all this. I just installed Google Hangouts if anyone is interested in chatting on there live when it's mutually convenient...you can find me on there as steveatwal<at>gmail<dot>com :-) Cheers

@BuzzingSteve - you can safely comment out that piece of code as well. The error is basically saying "hey, you have an object here that's not being used anywhere". The object is a dictionary, and we just commented out the only use of it. So, either ignore the error, or comment out that dictionary as well. (I was trying to keep the fix as simple as possible, which is why I didn't address it before)

Also, not to be picky, but some might disagree slightly with your comment that "the heart of the whole system is the plugins" ... for some, it certainly is. For others (like me), the heart of Buzztouch is the community! :)

oh, and to get picky with my own post - it's not an error, but a warning.

okay - time for bed. you guys keep me up too late! :)

@RedDog, @BuzzingSteve: I could not agree more. @Chris1's gonna have my job soon. The dude's been on a learning trajectory over the last few months that's straight up and to the right. Good stuff. The "plugin concept" remains the single most difficult part of what we do. All of us. Users, developers, us, everybody has a hard time with this. Of course dude's like @Chris1 seem to have less trouble than the rest of us because of his eagerness to dig things up and fix them. @Red Dog, too slow this time - ha! I say we have a hard time with it because it's a challenging problem to solve - making somebody else's idea flexible enough to work in "any" project without having to "know code". Combining the technical complexities with the idea that we all expect things to just work, all the time, across all sorts of devices...it's a tough nut to crack. Crackable, for sure, 100% bullet proof, not yet. Getting closer by the day. @Susan's done an amazing job helping us organize what I started last fall (allowing screens made by others to work in a BT project). You can't imagine how time consuming and challenging it is to field lists and lists of .zip packages containing all sorts of crazy-ness. One day it seems like it's getting better, the next, not so much. I can't imagine what Apple must go through in their famously complicated review process. Wowza. @Susan's super detailed. I'm not. Her and I go back-n-forth with all sorts of ideas and concepts as they relate to supporting the market and extensibility. The market's core purpose is to allow folks to take advantage of others' work without having to know code. Developers can charge or give away their work. We keep a small percentage of the fee's to help justify what's turned into a very very large amount of work. We've grown the market for a few months but do continue to struggle with the best way to move forward. It basically amounts to moving more OPEN or moving more CLOSED. Both have pros and cons. Determining the best approach is super-duper hard, risky, and loaded with consequences. This post, and this bug, is a perfect example of some competing ideas. On one hand, a more closed, "checklist, required testing, rules based" approach to the plugin market may have prevented this bug. On the other hand, a crazy-complicated and endlessly flexible table view cell may have never reached the market - had it been subjected to rules and rules and tests and tests. I made this UITableViewCell a few years ago so we could all use the same cell in all sorts of menu lists regardless of images, colors, row heights, font sizes, indicators, etc. It's worked well in thousands of projects. But, I still think this cell is too complicated for it's own good! Funny. It's hard to know where the Plugin Market will end up. More open or more closed. More diverse or less. A genuine opportunity for developers or a good way to waste some time. We're confident that if we stick with this long enough, pay attention to all the different stakeholders, stay focussed on transparency, and offer everyone a genuine opportunity - it will end up providing bug free, flexible, and professional screens to folks that dont' know code or would rather not write their own. @Chris1: Is your fix a actual fix or a workaround for this app? I'm happy to update this file with your change if it's actually fixed once and for all. It would sure be nice to put this crazy "blank cell" problem to rest! Way to go gang..this post brought a smile tonight...the camaraderie in this thread is awesome and I'm proud to be associated with all of you. Back to work I go...

@David. Well said :-) @Chris1. Thanks again, and you're right the buzztouch community is awesome :-)

Wow - thanks for the support! The fix should be an actual fix for this plugin. Turned out it had nothing to do with the bt_menu_cell class. That bohemoth of an object might warrant a discussion of its own, but it can rest easy tonight. (Which is more than I can say ... Our 10-month old just got back from spending a week with grandma and grandpa - his sleep pattern is all sorts of out of wack!)

Hi, @Chris: you're the man!!! Great find!!! Thanks!!! Best Regards, Danny

@chris1. LOL...it will get better. I remember when my daughter was that age (and now starting University)...seems like yesterday! :-)

@chris1: you are so right that Buzztouch is about community. I am so glad you are in our community! How did you learn so much in such a short time? You are absolutely brilliant. Thank you so much for taking the time to help us with this problem. @Red Dog: thank you for having the courage to bring the RSS feed to 2.0. We all knew it would be a challenging plugin but it also has the ability to add so much functionality to our apps. We appreciate it! Everyone: Together we can make Buzztouch into something truly great! The Plugin Market was just launched on September 1, and through it we have all been able to add new features to our apps and give the community an opportunity to sell plugins in the market. The market will grow, change, and evolve. It is an extension of the community as much as a way to add new functions to our apps.

@chris1 If I comment out that one line, I get warnings (not errors). I think it is safe to remove the whole "dictionary for row tapped" section. Agree? Thanks again.

Yep - the warning is just saying its not needed ... So safe to delete

Wow, finally found this thread :-) Indeed this fixed the bug and wondering why this is not in the code yet if you re-download the plugin ; Probably David too busy ^^ A downside of the fix is, that the different transitions of the screen load don't work anymore. Anyway that can be coded in again? Would need the flip transition.

@LeonG Thanks for recatching this. I fixed it in an earlier update but somehow let it slip back in. I will update the plugin when I get to work this morning and let you know.

Hey Red Dog, did you get the transitions to work again too?

HI Leon. Unfortunately this same line of code affects the transition too. [thisMenuItem setJsonVars:menuDict]; = "text on line disappears but transitions work" //[thisMenuItem setJsonVars:menuDict]; = "text on line stays but transitions fail" Maybe a superbrain like Chris1 or Kittsy will figure this out with one keystroke, but I will have to devote some time to come up with a working solution. Until then I have updated the plugin in the market to reflect the line remarked out, so transitions are broken but text stays visible.

ok, will forward it to Chris then, sure he can fix it and will let you know afterwards.