Hey guys! I was wondering if anyone with an Airprint-enabled printer would be able to help me test something out. A user of my app, TGfU Games PE (http://itunes.apple.com/us/app/tgfu-games-for-elementary-pe/id549014086?ls=1&mt=8) has reported that when she tries to print games from within my application, no matter which one she chooses, it always prints the same document. I just want to see whether this is an isolated incident or if it happens to any of you. Let me know if you're interested and I'll supply you with promo codes for the app!! Thank you guys, want to try and clear this up as soon as I can! Nicholas

I could test it for you

Thanks, Crown! Sent you the promo code through Buzztouch messages. Nicholas

got it, just tried printing Popcorn K-4, and Incoming K-4, and 21 prints for both? Also noticed that if the app loads in landscape on the ipad, Scringo does not load properly, I noticed this on a test app myself. Jim

Hmm.. odd. Any idea why the print function would work in this manner? Thanks again for taking a look, Jim! P.S. Scringo not loading properly, what exactly happens? Does it simply not load at all? Thanks! Nicholas

Also, this is the guide I followed to the tee in coding my Buzztouch app to allow printing for all my PDF files. http://jc-evans.com/wp-content/uploads/2012/07/Add-a-Print-Button-to-a-BT-App.pdf

there does not appear to be any log comments to see what path is printing in that code. Maybe add the following and debug to have the counsel print the file path when you hit the button? NSLog(@"path = %@", path); NSLog(@"dataFromPath = %@", dataFromPath); I am guessing here with the help of Google. Did you copy and paste the code for each of the screens from the 21 (3-6) screen? it may have copied the path as well somewhere? The Scringo issue was that sometimes when you open a app with Scringo in Landscape mode, it tries to build the slide bar in the wrong position. The little handle spins around and then when you rotate back to portrait the bar is always open and covers part of the screen horizontal. I just tried it again, and it worked fine. I have found it random on my app, and I have not found a fix. (although I have not contacted Scringo yet)

Hey Jim, Just a quick question for you! (sorry, it says "aspiring developer", not professional haha!). -Where would you add the NSLog code? pdfdoc.h or pdfdoc.m? And where exactly (before/after which line of code?)? Also, besides what was written in the guide, I didn't add anymore code elsewhere. All I did was add the "home" right button type on my Buzztouch control panel for all the PDFs I wanted to be printable. Thanks again, I appreciate it! Nicholas

No worries, not a pro here either, just like hacking this stuff up. I looked at the code a little more. Try putting the log after this in the .m file NSData *myData = [NSData dataWithContentsOfFile: path]; I am guessing at the location on this one. I believe the view utilities button method will come back to this and fire this in order. See how it is actually printing something this may be enough to tell us what path it is using every time. What does the counsel output now when you try to print? Is it more then the right nav button tap? Also in the PDF.m file check this line of code- NSArray *components = [shareTitle componentsSeparatedByString:@"."]; Share title might be what is giving us the title (and therefor the path) to the doc. I am guessing there would be an error if there was an error, but I would check there. No chance there is a name of that 21 PDF doc somewhere in the quotes of one of the lines of code? Once again just guessing here, but it gives you something to look at?

Hey Jim, I receive an error for the 2nd line of code for NSLog NSLog(@"dataFromPath = %@", dataFromPath); "Use of undeclared identifier 'dataFromPath'" Also, I tried looking, but the 21 PDF doc is nowhere to be found in any of the lines of code involving Airprint. Thanks for trying to continue in helping me out, I'm really stuck and had to developer reject my new app's binary due to the same print code being implemented within it.

you could try changing datafromPath to shareTitle? this may be barking up the wrong tree anyway. I am having a hard time in seeing why this works, but always with the same doc... Where this is effecting all the pages, maybe we should look at the BT_viewUtilities file. check the code you added. pay close attention to - target:theViewController I am guessing it was a copy/paste job, so I am not sure how it could be messed up, but it is the next thing I would look at. Feel free to shoot me a PM with a link to the .m file and I will take a look when I can as well.

That's exactly the same issue I'm having. The print function evidently works, but only with one document... WHY?!?! lol. It seems to always work alphabetically too. It always prints the 1st document alphabetically set up in Xcode... I don't know if this has anything to do with it as I've noticed this behavior in both my current app and my app due to be released when this issue is resolved. I took a look at the BT_viewUtilities file and nothing is out of the loop. All the code as it should be (dictated by the guide) is perfect as is. It seems like some code needs to be added or modified in order to include the rest of my PDFs. You could find a similar topic here on Buzztouch, I've tried to see if I get any luck in that thread as well: http://www.buzztouch.com/forum/thread.php?tid=FEC05AEB30B34A0A2EA2774&command=isSearching&currentPage=1&topicTitle=print&createdBy=&repliedBy=&minViews=-1&maxViews=-1&minReplies=-1&maxReplies=-1&forumCategory= Don't know if any of this helps... Thanks again, Jim, btw!

@GraciousWolf_PE Did you ever find the fix for always printing the same pdf (the first one alphabetically in the package) using MGoBlue's AirPrint instructions? I am having the same issue.