See this: http://milgra.blogspot.com/2012/10/qlpreviewcontroller-in-ios-6.html
It seems that Apple did some nasty things with QLPreviewController, it
started acting like a separate application over the mother
application, it intercepts all touch events, and nothing reaches
"UIApplication sendEvent:" . I've tried a lot of things to trick it,
subclassing and overriding touch events, adding its view to every
possible level, figuring out it's inner structure, adding a
semi-transparent overlay view and forwarding touch events, but nothing
worked.
I have same problems.
I had to give up Quick Look Framework and substitued UIWebView for QL althogh which doesn't make much sense.
Related
This problem started happening when I subclassed CCSprite (Entity) to recieve touch input. When I'm going away from the main scene by pushing to another, I make all Entities remove their delegation from the shared CCTouchDispatcher (ie onExit()). And then reactivate when the main scene returns (onEnterTransistionFinished()).
Half of the times this works fine. However, the other times this happens:
cocos2d: deallocing <CCScheduler: 0x2323a0>
Which I find rather strange. Is it even plausible that the Touch Delegates are the cause of the problem? Or is it perhaps memory-related?
Are you perhaps issuing [[CCScheduler sharedScheduler] release]? If so, don't do that.
The CCScheduler is a singleton. It should never deallocate by itself.
If I remember correctly the problem originated from trying to register/unregister the same Entity to/from the TouchDispatcher twice (ie it didn't have time to unregister/register before I tried registering/unregistering it again).
I solved it by adding a little BOOL _didRegisterWithTouchDispatcher to avoid doing something like that.
Back when I did LUA i used to run dofile("..."); to load other lua files and such. Later to find out that this is a very bad practice and can lead to applications breaks.
Now that I am on my way to developing a WebOs application, i want to make sure I am properly changing scene before i pick up bad programming habit.
At the moment this is what I use:
label2Tap: function(inSender, event) {
Mojo.Controller.stageController.popScene();
Mojo.Controller.stageController.swapScene("LogicAndArithmetic");
},
Which works great to get to my LogicAndArithmetic scene, is this the best practice to do such?
Thanks.
The scene model in the Mojo framework of webOS works like a stack. When the app starts you call pushScene to display your main scene. Normally, you then make additional pushScene calls to add scenes to the stack on top, and then when you are done with them they are popped, typically when the user performs the 'back gesture', bringing back the previous scene. Eventually you will be back at your main scene.
The swapScene call is equivalent to calling popScene and then pushScene for a different scene. In your case you are calling popScene then swapScene, so that is the equivalent of popping two scenes from the stack and then pushing back one. It probably works because you have only one scene, but if you had more it would not work correctly.
BTW, why are you working with Mojo and not Enyo?
While this is technically correct, it is most likely not how the user would expect your app to behave. In general, when a user presses a button that opens a new scene, it is placed on the stack, as Miguel said. The user will expect to be able to go back and pop the scene off of the stack. This happens automatically, you do not need to listen for this input. You do this by calling Mojo.Controller.pushScene("sceneName");. While there are some applications where swapScene makes sense, your app can probably be conceptualized as a stack of scenes, with a logical "back" scene.
I would reccommend playing around with some existing apps to get a feel for how they behave. Also, while Miguel suggested moving to Enyo, it is worth noting that Enyo apps are not officially supposed to work on webOS 2 devices (phones), only on the touchpad. It is possible to run them on webOS 2 devices, but I do believe that they will be rejected from the app catalog.
when i use pivot with in the panorama .pivot are used as a gallery view. i want to move pivot when i swipe it .but the problem is this because of both panorama and pivot are the same gesture event so both are they move .
i want swipe only my pivot view .
I would like some sample code or any other suggestion to do this.
so please give me a solution for doing this and
also give me a link where i easily understand this. Thanx in advance
You shouldn't have a Pivot in a Panorama control. End of discussion.
I believe it is achievable, because I've already solved similar issues with having WebBrowser control inside a custom horizontal-scrollable overview container like Pivot/Panorama, but believe me, it is NOT worth it. I've had to dig very deep into the visualstructure of the controls and attach my own manipulation-handlers to their viscera, manually choose which horiz/verti events to pass and which to cancel, and so on. This is not so easy, takes a lot of time, and doesn't guarantee that on the end you will have something behaving in a way you wanted to achieve in the first place. If you are not bound by some contract to preserve the shape of the UI, please, drop the idea and redesign your UI, just to save on your sanity and nerves.
But, if you are already insane or really want to dig where noone should, start on analysing your UI as a two rectangles: large pano and small pivo, and think which part should behave how on different possible touches/h-v swipes/h-v pans/pinches/so on. Write it down just to for reference, or soon you will probably start making small mistakes that will interfere with your understaning of the flow of the events.
I've checked the version I have, and "my" Panorama uses internally the UIElement.ManipulationXXXX events. In that case:
Display visualtrees of your UI and try attaching manipulation-events to every control. In those events, write/log which control's which handler was invoked. Then make some swipe/scroll on your APP and observe events. Analyze how they were bubbling and try cancelling (e.Handled=true) the manipulation-completed and/or manipulation-delta events somewhere between pivot and panorama. Your goal is to have the panorama see that e.Handled=true, while your pivot must see e.Handled=false. Your Pivot will probably see the event sooner than the Pano, so that point should be relatively easy.
If it fails to work, then you should check your version of the Pano, and check how it detects movements. If, for example, it uses the GestureListener - try the same trick with it. Etc.
And remember, you can always make your own horizontal-overwiew-container that will look like Pano, behave like Pano, and that will work with Pivo better - because it will be your code and you will tell it what and when to move. if you want to go this way, start on google and check all the preliminary Panorama previews that random people have published before that control was published by MS.
Okay, I'm fairly new to Cocoa and Objective-C, and to OOP in general.
As background, I'm working on an extensible editor that stores the user's documents in a package. This of course required some "fun" to get around some issues with NSFileWrapper (i.e. a somewhat sneaky writing and loading process to avoid making NSFileWrappers for every single document within the bundle). The solution I arrived at was to essentially treat my NSDocument subclass as just a shell -- use it to make the folder for the bundle, and then pass off writing the actual content of the document to other methods.
Unfortunately, at some point I seem to have completely screwed the pooch. I don't know how this happened, but closing the document window no longer releases the document. The document object doesn't seem to receive a "close" message -- or any related messages -- even though the window closes successfully.
The end result is that if I start my app, create a new document, save it, then close it, and try to reopen it, the document window never appears. With some creative subclassing and NSLogging, I managed to figure out that the document object was still in memory, and still attached to the NSDocumentController instance, and so trying to open the document never got past the NSDocumentController's "hmm, currently have that one open" check.
I did have an NSWindowController and NSDocumentController instance, but I've purged them from my project completely. I've overridden nearly every method for NSDocument trying to find out where the issue is. So far as I know, my Interface Builder bindings are all correct -- "Close" in the main menu is attached to performClose: of the First Responder, etc, and I've tried with fresh unsullied MainMenu and Document xibs as well.
I thought that it might be something strange with my bundle writing code, so I basically deleted it all and started from scratch, but that didn't seem to work. I took out my -init method overrides, and that didn't help either. I don't have the source of any simple document apps here, so I didn't try the next logical step (to substitute known-working code for mine in the readFromUrl and writeToUrl methods).
I've had this problem for about sixteen hours of uninterrupted troubleshooting now, and needless to say, I'm at the end of my rope. If I can't figure it out, I guess I'm going to try the project from scratch with a lot more code and intensity based around the bundle-document mess.
Hard to tell without code but I would suggest sending:
closeAllDocumentsWithDelegate:didCloseAllSelector:contextInfo:
... to the document controller and then looking at the controller as it is passed to the delegate to see how its state changes.
If the controller closes the document when you send the explicit message then your problem is with the binding to the window.
Is there a way to get colored checkboxes like in iCal without using custom drawing?
I have looked through the documentation but can only find how to change the background and text color.
You can achieve something at least similar to the colored checkboxes in iCal by enabling Core Animation for the checkbox and adding a "Hue Adjust" (in "Color Adjustment") content filter. If the color is static, this can be done entirely within Interface Builder, no code needed.
Be careful, though, as sometimes enabling Core Animation for various views causes strange bugs (for example, WebViews don't play nice with Core Animation views).
If you want to do it programmatically, take a look at the documentation for CIFilter (that's a link), which you use with the NSView instance method setContentFilters: (also a link).
It's a bit dated (runs back on 10.3), but Matt Gemmell published a some code for doing colored checkboxes a few years back.
http://mattgemmell.com/source
Look for "iTableView."
I looked at the code when it was first available, but not since. There might be a better way to do it at this point.
I'm afraid not. I'm not sure if the AHIG forbids this sort of thing or not, (it probably does), but the reason iCal gets away with it is because, 'Hey! Why not?'. Also, it's an Apple application, so yeah.
It can still be done, of course, but not without custom drawing. Personally, I'd advise against it, and rather see if what you are trying to achieve could be achieved some other way. If not, you could possibly use some of the data files from iCal to build your checkbox. (Unsure of how kosher that would be, but 'Hey! Why not?'.)