Now i have one issue during ios app development.
I made one viewpagercontrollerview include several viewcontroller.
Each Viewcontroller include tableview.
I used UISearchController in this tableview.
But, whenever i click searchcontroller and tab scrolled, then error is occured.
2016-08-08 22:07:11.211 ToolManager[3913:121312] *** Assertion failure in -[_UIQueuingScrollView _setWrappedViewAtIndex:withView:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/UIKit_Sim/UIKit-3512.60.7/_UIQueuingScrollView.m:332
2016-08-08 22:07:11.222 ToolManager[3913:121312] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Unexpected subviews'
*** First throw call stack:
(
0 CoreFoundation 0x0000000104c3dd85 __exceptionPreprocess + 165
1 libobjc.A.dylib 0x00000001046b1deb objc_exception_throw + 48
2 CoreFoundation 0x0000000104c3dbea +[NSException raise:format:arguments:] + 106
3 Foundation 0x00000001042fbd5a -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 198
But, Without click searchcontrol and scroll,then work is done well.
I saw several resolution...
one method is dismiss searchcontroller before scrool tab.
But how can i capture tab scroll!
now I add searchcontroll in each viewcontroller.
#interface CurrentToolListViewController : BaseViewController<UITableViewDelegate, UITableViewDataSource,
UISearchResultsUpdating, UISearchControllerDelegate>
#property (nonatomic, strong) UISearchController *searchController;
#property (nonatomic, copy) NSString *filterString;
#end
and .m file
self.searchController = [[UISearchController alloc] initWithSearchResultsController:nil];
self.searchController.searchResultsUpdater = self;
self.searchController.dimsBackgroundDuringPresentation = NO;
self.searchController.delegate = self;
[self.searchController.searchBar sizeToFit];
self.tblCurToolList.tableHeaderView = self.searchController.searchBar;
self.definesPresentationContext = YES;
pls help me.
You have to make your searchController inactive in your viewWillDisappear(_:) method
-(void) viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
self.searchController.active = NO;
}
Edit
The above code should fix your app from crashing if you swipe to the next ViewController, but if you are using a UIButton to call setViewController, then you have to check if the searchController is active (using an if statement) in the UIButton's #IBAction. Inside the if statement, type self.searchController.active = NO;, and then return.
This just makes the searchController inactive, and then you have to press the button again to make it call the appropriate method (setViewController)
Related
In our app we have a UITableViewController that has a UISearchController:
searchController = [[UISearchController alloc] initWithSearchResultsController:nil];
self.searchController.searchResultsUpdater = self;
[self.searchController.searchBar sizeToFit];
self.tableView.tableHeaderView = self.searchController.searchBar;
self.showFooterView = YES;
self.searchController.delegate = self;
self.searchController.dimsBackgroundDuringPresentation = NO; // default is YES
self.searchController.searchBar.delegate = self;
self.definesPresentationContext = YES;
The table view controller is also a UISearchBarDelegate
and UISearchControllerDelegate.
#pragma mark - UISearchBarDelegate
- (void)searchBarSearchButtonClicked:(UISearchBar *)searchBar {
[searchBar resignFirstResponder];
}
- (void)searchBarCancelButtonClicked:(UISearchBar *)searchBar {
self.contacts = self.allContacts;
[self.tableView reloadData];
}
Now everything works as expected, but there are occasions when a user starts a search, types in a few characters in the search bar, results are returned, and the user cancels the search and then this happens:
Fatal Exception: NSInvalidArgumentException
-[_UIFullscreenPresentationController adaptivePresentationController]: unrecognized selector sent to instance 0x147c81ce0
Fatal Exception: NSInvalidArgumentException
0 CoreFoundation 0x1842b4f48 __exceptionPreprocess
1 libobjc.A.dylib 0x198d77f80 objc_exception_throw
2 CoreFoundation 0x1842bbc5c __methodDescriptionForSelector
3 CoreFoundation 0x1842b8c00 ___forwarding___
4 CoreFoundation 0x1841bccac _CF_forwarding_prep_0
5 UIKit 0x18a1ba084 -[UISearchController _searchPresentationController]
6 UIKit 0x189e7d10c -[_UISearchControllerTransplantSearchBarAnimator animateTransition:]
7 UIKit 0x189b9fa90 __56-[UIPresentationController runTransitionForCurrentState]_block_invoke
8 UIKit 0x189af856c _runAfterCACommitDeferredBlocks
9 UIKit 0x189b054bc _cleanUpAfterCAFlushAndRunDeferredBlocks
10 UIKit 0x189839984 _afterCACommitHandler
11 CoreFoundation 0x18426bbd0 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__
12 CoreFoundation 0x184269974 __CFRunLoopDoObservers
13 CoreFoundation 0x184269da4 __CFRunLoopRun
14 CoreFoundation 0x184198ca0 CFRunLoopRunSpecific
15 GraphicsServices 0x18f3d4088 GSEventRunModal
16 UIKit 0x1898b0ffc UIApplicationMain
We have never been able to reproduce this error, although it gets reported by Fabric on production.
This problem looks similar to this: Selecting cell after search doesn't segue visually, but loads next view Swift Xcode but no real answer has been given there yet.
I have started looking into presentation controllers but we have no special functionality that would require setting up presentation controllers in a specific way.
Any ideas on how to fix this?
Thanks
I've faced the same problem on Swift.
The problem is Searchbarcontroller still hold the reference(delegate) of your ViewController.
So all you have to do is manually remove the reference when view dealloc or disappear
Something like this:
- (void)dealloc {
self.searchController.searchResultsUpdater = nil;
self.searchController.searchBar.delegate = nil;
self.searchController.delegate = nil;
self.searchController = nil;
}
Try cleaning all your references as given below.
-(void)dealloc{
if (_searchController) {
_searchController.searchResultsUpdater = nil;
_searchController.searchBar.delegate = nil;
_searchController.delegate = nil;
}
}
Utilize UISearchContainerViewController as Main ViewController and wrap your SearchController inside it.
A view controller that manages the presentation of search results in your interface.
Although you can present a search controller object modally, you should never push one onto a navigation controller’s stack or use one as a child of another container view controller. Instead, embed an instance of this class and let it manage the presentation of the search controller’s content.
https://developer.apple.com/documentation/uikit/uisearchcontainerviewcontroller
I'm having a weird issue with UIViews and manual memory management.
I have a view (contentView) which is the main view of a view controller.
After a long press on the contentView, another view is supposed to fade in (on top of it).
When the gestures ends, the additional view fades out.
The issue is:
When the contentView receives a long press, I create the auxiliary view, add it to the contentView, and then release it, which is/was the common practice back in the pre-ARC days.
It works okay on the iPhone, but it crashes on the iPad!
The crashy line is:
[ZPNowPlayingItemInfoView dealloc]
...which gets triggered when I remove the auxiliary view from the contentView.
Any clues on why this happens?
If I comment out the release line (see my comment in the code), it works flawlessly on both devices, but it feels bad.
Here's the code:
-(void)longPressDetected:(UILongPressGestureRecognizer*)longPressGR
{
//Content view of the view controller I'm in
UIView *contentView = MSHookIvar<UIView*>(self, "_contentView");
if (longPressGR.state == UIGestureRecognizerStateBegan) {
id item = MSHookIvar<MPAVItem*>(self, "_item");
ZPNowPlayingItemInfoView *infoView =
[[ZPNowPlayingItemInfoView alloc] initWithFrame:
CGRectMake(0,0,contentView.frame.size.width,contentView.frame.size.height)
item:item];
//infoView retain count: 1
[infoView setAlpha:0.f];
[contentView addSubview:infoView];
//infoView retain count: 3 (???)
//iPad goes berserk on this line
//Commented - Works both on iPhone and iPad
//Uncommented - Works only on iPhone
//[infoView release];
//infoView retain count: 2 (if release is uncommented)
[UIView animateWithDuration:0.35f animations:^{
[infoView setAlpha:1.0f];
} completion:^(BOOL finished) {
//infoView retain count: 3
}];
} else if (longPressGR.state == UIGestureRecognizerStateEnded) {
ZPNowPlayingItemInfoView* infoView = nil;
for (UIView *subview in contentView.subviews) {
if ([subview isKindOfClass:[ZPNowPlayingItemInfoView class]]) {
infoView = (ZPNowPlayingItemInfoView*)subview;
break;
}
}
[UIView animateWithDuration:0.35f animations:^{
[infoView setAlpha:0.f];
} completion: ^(BOOL finished){
[infoView removeFromSuperview];
}];
}
P.S. I need to use manual memory management. This is a tweak for jailbroken devices.
Stack trace:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x195287bdc 0x19526c000 + 0x1bbdc // objc_msgSend + 0x1c
1 + Musix.dylib 0x10015b19c 0x100154000 + 0x719c // -[ZPNowPlayingItemInfoView dealloc] + 0x48
2 libsystem_blocks.dylib 0x19590d90c 0x19590c000 + 0x190c // _Block_release + 0xfc
3 UIKit 0x188ef8590 0x188eb0000 + 0x48590 // -[UIViewAnimationBlockDelegate dealloc] + 0x44
4 CoreFoundation 0x1845f1374 0x1845ec000 + 0x5374 // CFRelease + 0x208
5 CoreFoundation 0x184601004 0x1845ec000 + 0x15004 // -[__NSDictionaryI dealloc] + 0x8c
6 libobjc.A.dylib 0x19528d720 0x19526c000 + 0x21720 // (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 0x230
7 CoreFoundation 0x1845f4f90 0x1845ec000 + 0x8f90 // _CFAutoreleasePoolPop + 0x18
8 CoreFoundation 0x1846c774c 0x1845ec000 + 0xdb74c // __CFRunLoopRun + 0x5d8
9 CoreFoundation 0x1845f51f0 0x1845ec000 + 0x91f0 // CFRunLoopRunSpecific + 0x188
10 GraphicsServices 0x18d7575a0 0x18d74c000 + 0xb5a0 // GSEventRunModal + 0xa4
11 UIKit 0x188f26780 0x188eb0000 + 0x76780 // UIApplicationMain + 0x5cc
12 Music (*) 0x10006ee28 0x100064000 + 0xae28 // 0x0000adac + 0x7c
13 libdyld.dylib 0x1958e2a04 0x1958e0000 + 0x2a04 // start + 0x0
ZPNowPlayingItemInfoView:
#interface ZPNowPlayingItemInfoView()
#property (nonatomic, retain) MPAVItem* item;
#property (nonatomic, retain) MPUSlantedTextPlaceholderArtworkView *artworkView;
#property (nonatomic, retain) UILabel *artistLabel;
#property (nonatomic, retain) UILabel *albumLabel;
#property (nonatomic, retain) UILabel *songLabel;
#end
ZPNowPlayingItemInfoView dealloc:
-(void)dealloc
{
[super dealloc];
[self.item release];
[self.artworkView release];
[self.artistLabel release];
[self.songLabel release];
}
You have some problem in ZPNowPlayingItemInfoView class. When this problem happens? Only when the object gets deallocated. When you comment [infoView release] out, your object is never deallocated and the problem doesn't arise - you will have a memory leak though.
Inspect what ZPNowPlayingItemInfoView does, especially its dealloc method. Are you sure you are constructing it correctly? Is item always a valid object?
After seeing the ZPNowPlayingItemInfoView dealloc method, the problem is quite clear - [super dealloc] must always be the last call, not the first one. Once you have deallocated the object, accessing its properties is an undefined operation.
When commenting out the release is a working workaround, that indicates that you have released it once too often. It may well be the very one release that you commented out.
removeFromSuperview does reduce the retain count by 1.
I suggest re-visiting the full life cycle of the view object. This can be tricky though. Each retain needs to have exactly one corresponding release or autorelease. Assigning the view to a property using its getter (self.myView = subview) does retain it and re-assigning another view to the property (self.myView = someOhterview) releases subview.
On the contrary accessing the iVar directly (myView = subview) does not maintain the release/retain-cycle.
There is more than that. Adding the view and removing it from an array, set or dictionary will change the retain count accordingly.
So go and have a deeper look at it. Use instruments to observe the retain count.
I have two methods that toggle the right bar button items in a view controller's UINavigationItem. It's basically to show a search bar in the navigation bar when the search button is tapped, and to hide the search bar when the user executes a search
- (void)displaySearchUI
{
[self.mainNavigationController.topViewController.navigationItem setRightBarButtonItems:[self searchOpenItems] animated:YES];
[self.searchBar becomeFirstResponder];
}
- (void)dismissSearchUI
{
[self.mainNavigationController.topViewController.navigationItem setRightBarButtonItems:[self searchClosedItems] animated:YES];
}
- (NSArray *)searchClosedItems
{
return #[[self someCustomItem],
[self someOtherItem],
[self searchButtonItem],
];
}
- (NSArray *)searchOpenItems
{
return #[[self someCustomItem],
[self someOtherItem],
[self searchBarItem],
];
}
the item returned from searchButtonItem uses a UIBarButtonItem with an image, while the item returned from searchBarItem has a custom view of a UISearchBar. the other items in each are identical in each search state.
When I call displaySearchUI, the searchbar becoming the first responder opens a popover to show some search suggestions. When the popover is dismissed by the user, dismissSearchUI is called via the popoverControllerDidDismissPopover: delegate method. However at that point, often the app encounters a crash within UINavigationBar:
-[CALayer enumerateObjectsUsingBlock:]: unrecognized selector sent to instance 0x7de9ac80
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[CALayer enumerateObjectsUsingBlock:]: unrecognized selector sent to instance 0x7de9ac80'
*** First throw call stack:
(
0 CoreFoundation 0x056f0946 __exceptionPreprocess + 182
1 libobjc.A.dylib 0x05379a97 objc_exception_throw + 44
2 CoreFoundation 0x056f85c5 -[NSObject(NSObject) doesNotRecognizeSelector:] + 277
3 CoreFoundation 0x056413e7 ___forwarding___ + 1047
4 CoreFoundation 0x05640fae _CF_forwarding_prep_0 + 14
5 UIKit 0x03ba38aa -[UINavigationBar _setLeftViews:rightViews:] + 3774
6 UIKit 0x03b8f77e -[UINavigationItem updateNavigationBarButtonsAnimated:] + 186
7 UIKit 0x03b901a0 -[UINavigationItem setObject:forLeftRightKeyPath:animated:] + 600
8 UIKit 0x03b9100a -[UINavigationItem setRightBarButtonItems:animated:] + 104
9 MyApp 0x0028088b -[DisplayManager dismissSearchUI] + 283
I'm not sure exactly what could be happening here. It seems to happen whether or not setting the items is animated. It also only happens when the user taps outside the popover. If I programmatically dismiss the popover and call dismissSearchUI, there's no crash (I imagine due to the different order in which the animations occur, or due to some state differences in the UI when the user dismisses a popover vs a programmatic dismissal. I've tried to work around it by doing this:
#pragma mark - UIPopoverControllerDelegate
- (BOOL)popoverControllerShouldDismissPopover:(UIPopoverController *)popoverController
{
[self dismissSearchSuggestionsUI];
return NO;
}
- (void)dismissSearchSuggestionsUI
{
[self.popoverController dismissPopoverAnimated:YES];
[self.displayManager dismissSearchUI];
}
But I get an EXC_BAD_ACCESS crash instead here, (with a similar stack trace that leads me to believe it's the same issue, just a different symptom due to timing).
Has anyone encountered something like this, and is there a way to work around this without having to disable manual user popover dismissals altogether?
Bah, i figured it out right after posting. By ammending dismissSearchUI's method to do this:
- (void)dismissSearchUI
{
[self.searchBar resignFirstResponder]
[self.mainNavigationController.topViewController.navigationItem setRightBarButtonItems:[self searchClosedItems] animated:YES];
}
I resolved the issue. I figured that the search bar would resign its own first responder when the user executed a search, but that doesn't happen automatically when the user manually cancels the search which causes the bar button item it's in to be removed from the nav bar.
Since upgrading to XCode 5/iOS 7, I'm getting the following error when calling a function which is supposed to present the Redlaser SDK barcodepickercontroller:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present a nil modal view controller on target .'
* First throw call stack:
(
0 CoreFoundation 0x02ef25e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x028dd8b6 objc_exception_throw + 44
2 UIKit 0x006e817a -[UIViewControllerpresentViewController:withTransition:completion:] + 4879
3 UIKit 0x006e8caf -[UIViewController presentViewController:animated:completion:] + 130
4 UIKit 0x006e8cef -[UIViewController presentModalViewController:animated:] + 56
5 Extinguishers 0x0000b703 -[LoginViewController scanPressed] + 1299
And here's my method which causes it:
-(IBAction) scanPressed
{
if (overlayController.parentPicker == nil)
{
BarcodePickerController * picker = [[BarcodePickerController alloc] init];
[picker setOverlay:overlayController];
[picker setDelegate:self];
// Initialize with portrait mode as default
picker.orientation = UIImageOrientationUp;
// The active scanning region size is set in OverlayController.m
}
// Update barcode on/off settings
[overlayController.parentPicker setScanUPCE:YES];
[overlayController.parentPicker setScanEAN8:YES];
[overlayController.parentPicker setScanEAN13:YES];
//[overlayController.parentPicker setScanSTICKY:YES];
//[overlayController.parentPicker setScanQRCODE:YES];
[overlayController.parentPicker setScanCODE128:YES];
[overlayController.parentPicker setScanCODE39:YES];
[overlayController.parentPicker setScanITF:YES];
// Data matrix decoding does not work very well so it is disabled for now
[overlayController.parentPicker setScanDATAMATRIX:NO];
// hide the status bar
[[UIApplication sharedApplication] setStatusBarHidden:YES];
// Show the scanner overlay - THIS LINE CAUSES THE CRASH
[self presentModalViewController:overlayController.parentPicker animated:TRUE];
}
I've also tried upgrading to the latest version of the Redlaser SDK, and the error is still the same. I did not have this problem before switching to iOS 7 as the base SDK.
The only thing I can think of is that picker(the parent) might be going out of scope and getting deallocated. Put a test right before the buggy line to check if the parent still exists: if(overlayController.parentPicker == nil) NSLog(#"Parent is nil");
If it really is nil (like your original error is saying), try declaring picker before that first if statement.
BarcodePickerController *picker;
if(overlayController.parentPicker == nil)
{
picker = [[BarcodePickerController alloc] init];
//...
The child might only have a weak pointer to the parent, so you may need to declare the parent as a #property or somewhere where it won't be deallocated before your viewController is popped off the stack.
My app built natively with CocoaTouch and ARC crashes when deallocating a UIView subclass instance.
Here is the crash log.
OS Version: iOS 6.1.3 (10B329)
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000008
Crashed Thread: 0
0: 0x39de65b0 libobjc.A.dylib objc_msgSend + 16
1: 0x31edb694 CoreFoundation -[NSArray makeObjectsPerformSelector:] + 300
2: 0x33d8c57a UIKit -[UIView(UIViewGestures) removeAllGestureRecognizers] + 146
3: 0x33d8c144 UIKit -[UIView dealloc] + 440
4: 0x00240b36 MyApp -[StandardPanelView .cxx_destruct](self=0x20acba30, _cmd=0x00240985) + 434 at StandardPanelView.m:139
5: 0x39deaf3c libobjc.A.dylib object_cxxDestructFromClass(objc_object*, objc_class*) + 56
6: 0x39de80d2 libobjc.A.dylib objc_destructInstance + 34
7: 0x39de83a6 libobjc.A.dylib object_dispose + 14
8: 0x33d8c26a UIKit -[UIView dealloc] + 734
9: 0x0022aa14 MyApp -[StandardPanelView dealloc](self=0x20acba30, _cmd=0x379f1a66) + 156 at StandardPanelView.m:205
10: 0x39de8488 libobjc.A.dylib (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 168
11: 0x31e98440 CoreFoundation _CFAutoreleasePoolPop + 16
12: 0x31f28f40 CoreFoundation __CFRunLoopRun + 1296
13: 0x31e9bebc CoreFoundation CFRunLoopRunSpecific + 356
14: 0x31e9bd48 CoreFoundation CFRunLoopRunInMode + 104
15: 0x35a502ea GraphicsServices GSEventRunModal + 74
16: 0x33db1300 UIKit UIApplicationMain + 1120
17: 0x00113c50 MyApp main(argc=1, argv=0x2fd3ed30) + 140 at main.m:23
The questions are:
what could be set wrong that makes the internal call to [UIView(UIViewGestures) removeAllGestureRecognizers] crash. One theory is that some gesture in the gestures array is deallocated already somewhere else.
When a UIView contains subviews, how is the sequence of deallocation process?
Some extra background info:
The crash happens, but there is no exact way to reproduce it.
The StandardPanelView instance works as delegate for gestures belongs to its subviews.
We are using flyweight on StandardPanelView instances, i.e., caching and recycling.
Thanks in advance for any hint about how this crash could happen.
My first impression is that you might be trying to access the StandardPanelView, which has just gotten deallocated.
What could be set wrong that makes the internal call to [UIView(UIViewGestures) removeAllGestureRecognizers] crash. One theory is that some gesture in the gestures array is deallocated already somewhere else.
It will not be because a UIGestureRecognizer got deallocated. The UIView strongly holds the UIGestureRecognizers in an NSArray. They will not be deallocated while they are still in the array.
However, the UIGestureRecognizer's delegate may have gotten deallocated. That is only an (assign) property, meaning that it is -not- strongly held, and if the delegate is deallocated, it will be a dangling pointer. So, if in [NSArray makeObjectsPerformSelector:] the delegate is used, this might happen.
When a UIView contains subviews, how is the sequence of deallocation process?
Objects are deallocated from 'parent' to 'child', ie. the superview is deallocated, then the subview, then the gesture recognizers. (Although whether the subviews are dealloced before the gesture recognizers is an implementation detail, so you probably shouldn't depend on it).
We can see this in a simple sample controller:
// The UIView that will be used as the main view
// This is the superview
#interface MyView : UIView
#end
#implementation MyView
- (void)dealloc {
NSLog(#"Dealloc MyView");
}
#end
// This view will be put inside MyView to be used as a subview
#interface MySubview : UIView
#end
#implementation MySubview
- (void)dealloc {
NSLog(#"Dealloc MySubview");
}
#end
// This is the gesture recognizer that we will use
// We will give one to each view, and see when it is deallocated
#interface MyGestureRecognizer : UIGestureRecognizer
#property (nonatomic, copy) NSString *tag;
#end
#implementation MyGestureRecognizer
#synthesize tag;
-(void)dealloc {
NSLog(#"Dealloc MyGestureRecognizer tag: %#", tag);
}
#end
// Just a test view controller that we will push on/pop off the screen to take a look at the deallocations
#interface TestViewController : UIViewController
#end
#implementation TestViewController
- (void)loadView {
self.view = [[MyView alloc] init];
MyGestureRecognizer *recognizer = [[MyGestureRecognizer alloc] initWithTarget:self action:#selector(doStuff)];
recognizer.tag = #"MyViewGestureRecognizer";
recognizer.delegate = self;
[self.view addGestureRecognizer:recognizer];
}
- (void)viewDidLoad {
[super viewDidLoad];
MySubview *subview = [[MySubview alloc] init];
MyGestureRecognizer *recognizer = [[MyGestureRecognizer alloc] initWithTarget:self action:#selector(doStuff)];
recognizer.tag = #"MySubviewGestureRecognizer";
recognizer.delegate = self;
[subview addGestureRecognizer:recognizer];
[self.view addSubview:subview];
}
- (void)doStuff {
// we don't actually care what it does
}
#end
All we are doing is adding MyView to be the main view for TestViewController, and then adding a MySubview inside MyView. We also attach a MyGestureRecognizer to each of the views.
When we push it off the screen, our log output presents:
Dealloc TestViewController
Dealloc MyView
Dealloc MySubview
Dealloc MyGestureRecognizer tag: MySubviewGestureRecognizer
Dealloc MyGestureRecognizer tag: MyViewGestureRecognizer
Sorry for the long answer... It has been about 3 months since you posted it, so maybe you already solved the problem, but in case anyone else stumbles across this answer, I hope it helps out.