Im using VIEWER_RESIZE_EVENT to catch when viewer resize but it raise all the time even it doesnt has any change (take a look attached pic). And when i use that method, objects do not highlight when mouse move over anymore. I solved the problem by different way is catch resize div event, it works perfectly. SoVIEWER_RESIZE_EVENT really has a problem or i misunderstand how to use it?
Appreciated any comments.
The VIEWER_RESIZE_EVENT definitely shouldn't be called all the time. Such a behavior is usually a sign of some problematic JavaScript code where, for example, some piece of code reacts to this event and (accidentally or intentionally) causes some change in the viewer size, causing an infinite loop of resize events.
When you try any of the official sample apps, you'll see that the event is really only triggered when the viewer canvas size actually changes.
Related
this is a weird one.
In our Flash project, we add a listener for stage resize events so we can do some dynamic resizing. At the moment we're not running it in a browser, just testing it in the standalone Flash player, and it has been working fine but recently, for some reason the events are no longer being triggered. What's odd is that it appears to be something code-related because when I switch over to a different chunk of code, the events still trigger - but I can't see any reason for it. The listener is still on the stage and its willTrigger is still true.
I know this is all a bit vague, but any suggestions would be valuable!
Again, just to be very clear, I'm not talking about running it in a browser, so this isn't anything to do with setting the resize settings in HTML.
Thanks
Well, if it were an AIR app i would suggest adding your event listener to NativeApplication.nativeApplication instead of the stage, a long time ago i had a similar intermittent problem and that was the fix. However i think thats only available for AIR. You can try to change your publiah settings to an AIR app just to see if it works. If it still doesnt work id have to assume its something code related on your part. willTrigger sounds suspicious :)
Using Flex SDK 4.14.1.
What event is fired when a component comes into view after scrolling a scroller?
I have a mobile app with a scroller component and it has a lot of items (about 4 screens worth of data), now I was wondering if a particular event was fired when these components came into view (drawn on the screen)?
What I want to do is dispatch an event when we get to a certain point down the 'page', but I cannot see any way to do this. I have tried creationComplete, show and addedToStage but they all seem to fire when the view is created, what I want is a solution something like the List component where items are rendered just before they are drawn on the screen.
Any suggestions greatly welcomed as dispatching these events at the start would both be a total waste of bandwidth, and a drain on resources that are valuable.
Thanks
So, in summary, there isn't one? Ah, ok, well that's fair enough.
I ended up putting a -load more- button in and calling my commands from that, works perfectly.
I am asking Apache to put in an event when an item is rendered on the screen, who the hell wants to load all of their data at start?
So, this is pretty silly. I'm working on a banner ad that utilizes the clicktag. It's a surprisingly fancy one that uses pointroll, and when you hover over the 300x250 banner ad, it pulls up a larger one overtop of it that is bigger and much more interactive. In total, the larger banner has 29 clicktags, all using the variables "clickTag1" to "clickTag29".
The banners are all done, everything fires correctly (according to my trace statements). However, I'm in the middle of QA, testing all of the clicktags using this validator: https://flashval-temp.appspot.com/validator/ , when suddenly, it stops working after clickTag20. I thought it may have been the validator at first, so I tried other validators. No luck. I went back into my code (everything is a duplicate of one template, so the only code changes made were the changes to the string), and made sure to test it again. They're firing off just fine according to my trace statements.
Finally, and this doesn't seem to make sense to me, but I switched the variables clickTag20 and clickTag21. The button that fired off clickTag20 worked, so I assigned it clickTag21. The button that was assigned clickTag21 was the first to stop working, so I assigned it clickTag20. When I ran that through the validator, the button that was assigned to clickTag20, regardless of which button it was, worked! The one that was assigned clickTag21 never did, also regardless of which button it was fired off from.
The variable is a string of a paramObj. How does the content of that string matter? I would have assumed it was compile order, but even in that case, clickTag21 should have fired and not clickTag20. What is going on here? Has anyone else experienced this? If so, did you have a workaround? Please and thank you!!
Here is the thing... when you set a clicktag you're waiting for a flashvar. A parameter sent from the HTML to your SWF file. (more: http://helpx.adobe.com/flash/kb/pass-variables-swfs-flashvars.html)
Usually you'd test, if this parameter doesn't exists, the banner should do nothing, otherwise, open the link.
Turns out, and this is a guess, that these validators don't know how many clicktags you have in your flash file - or how many parameters you're waiting for - , so they pass up to 20 variables to your flash file, which is more than reasonable.
The bottom line is: if your events are working, you should be fine. Pointroll has a QA team, if something comes up, they will let you know, but as far as I can see from here, you should be fine.
Good luck
I'm encountering a problem while attempting to add functionality like pinch-zoom to an application that features an Image control inside of a ScrollView, which is inside a FlipView. The Image control and ScrollView control are in the ItemTemplate of the FlipView.
The idea is that if the user pinch-zooms on the Image it will activate code which will create and display an enlarged version of the image in the Image control. (The Image control in this case contains a PDF page, so we want a bigger version of the PDF page, instead of just an enlarged and fuzzier view of the PDF page).
If I attach a ManipulationDelta event handler to the Image, it will catch ManipulationDelta events produced by the pinch-zoom gesture, which I can then use to create the PDF zoom effect. However...now it will not catch scroll (drag?) gestures. Or rather, these too get caught by the ManipulationDelta event handler. I'd rather avoid having to implement code at this point to handle scrolling programmatically. Do I have any options for somehow bubbling up (or "over"?) the ManipulationDelta events to whatever would handle the scrolling? I would think this would happen already, the event would bubble up to the ScrollView which would then handle scrolling. But it appears to not be happening that way.
I have e.Handled set to false in the ManipulationDelta event handler. And the ManipulationMode on the IMage control is set to "All". I've tried "Scale" but this didn't help.
Thank you!
The ScrollViewer in WinRT is optimized for performance and uses DirectManpulation under the hood. That's why it's tricky to have both scrolling from the ScrollViewer and gestures inside it.
This blog post from Rob Caplan (MS employee) gives more information:
http://blogs.msdn.com/b/wsdevsol/archive/2013/02/16/where-did-all-my-gestures-go.aspx
Unfortunately there is no good solution if the app needs both scrolling and gestures (for example, to detect CrossSlides against the scrolling). In this case the only option to get the Pointer messages everywhere is to disable Direct Manipulation everywhere, but that disables scrolling as well. To get that back the app will need to detect the scrolling gestures itself and then navigate the ScrollViewer to the new location with ScrollToHorizontalOffset or ScrollToVerticalOffset or by updating the SelectedIndex. This is tricky and will be noticeably slower than letting the ScrollViewer do its thing. It should be avoided if at all possible.
Hope this helps
I'm trying to make an extension for Google chrome which requires me to be able to identify the currently selected tab. I did this with the chrome.tabs.onSelectionChanged method, however when I switch windows this isn't fired. I plan to use chrome.windows.onFocusChanged to detect when the window changes then use the chrome.tabs.getSelected method. However the problem is that chrome.windows.onFocusChanged seems to be fired more than once. If I'm not mistaken, it returns window -1, then the first window created (usually 1), then the current window. If the first window is selected then it's fires -1, then 1.
Am I using the right method here? Is there a better way of doing this? If I stick with it I might need to keep track of how window changes which is a bit messy.
Kinda worked on my own solution for this. For anyone interested in doing something similar, what I did instead was to use the onFocusChanged as an indicator that there is a window change happening which then starts a requestListener. Using content scripts, I sent a request to the extension whenever there was a window.focus event indicating that the focus is already on that window. The requestlistener then just removes itself. Unfortunately this approach requires all tabs to send requests every time they get focus. Some more tweaking to fix that I guess but for the mean time I think that suffices since sending requests every time there is a change of focus doesn't seem to eat up that much resources.