Search Results

Search found 7 results on 1 pages for 'mahboudz'.

Page 1/1 | 1 

  • iPad: Tables in Popover Views do not Scroll to Show Selected Row

    - by mahboudz
    I am having two problems with viewcontrollerss in landscape orientation on the iPad. (1) I have two popups which hold tables. The tables should scroll to a specific row to reflect a selection in the main view. Instead, the tables do scroll down some but the actual selected row remains off screen. (2) All my action sheets come up with a width of 320. In Interface Builder, all my views are created in landscape orientation. Only the main Window is not, but I don't see a way to change that. My Configuration: Upon launch, I get the following coordinates for my main window and the main viewcontroller view: Window frame {{0, 0}, {768, 1024}} mainView frame {{0, 0}, {748, 1024}} All other views after that show these coordinates when summoned (when loaded but before being presented): frame of keysig {{0, 0}, {1024, 768}} frame of instrumentSelect {{20, 0}, {1024, 768}} frame of settings {{0, 0}, {467, 300}} In all my viewControllers, i respond to shouldAutorotateToInterfaceOrientation with: return ((interfaceOrientation == UIInterfaceOrientationLandscapeLeft) || (interfaceOrientation == UIInterfaceOrientationLandscapeRight)); Everything (almost) functions as expected. The app launches into one of the two landscape modes. The views (and viewcontrollers) display everything where it belongs and taps work all across the screen as expected. However, I still have the two problems. Problem 1: I have two popups containing tables long enough to run off screen. The tables should scroll to a selected row. They do scroll i.e. they don't start visually at row 1 but they don't scroll enough to actually show the selected row. It almost seems like a UITable internal rect gets created with the wrong number and stays that way but I've checked both of the UITableView's scrollView content coordinates and they seemed reasonable. Problem 2: I think this is related to problem 1 because my actionsheets come up with a width of 320. I can only assume that the iPad allows actionSheets in only 320 or 480 widths and since it somehow thinks that the screen is oriented in portrait mode, it uses the narrower width. There you have it. I can't believe I am still getting hung up on orientation issues. I swear Apple doesn't make it easy to have a landscape app. Any ideas?

    Read the article

  • Difficulty with apps with a forced landscape orientation

    - by mahboudz
    I have two apps, both of which force the user to use the iPhone in landscape mode, in order to have a wider screen, instead of a taller one. One of the things I have found is that my first view will look fine, but all other views come up with their subviews (UIButtons, UIPicker, UIViews) squeezed to one side or clipped (depending on whether the elements were set to move, resize or stay in the same position as the view size changed). All my views are designed in IB in the landscape orientation. My underlying UIWindow, and everything I can think of has been laid out in landscape orientation. Even my plist file has the UIInterfaceOrientationLandscapeRight flag set. Now, if I load all my views at the same time as my rootview controller, then I have no problems. But if I have views loaded later, they get clipped or squeezed. The only way to get around the problem was to add the following line in my code that flips in a new view: [coming.view setFrame:CGRectMake(0, 0, 480, 300)]; Anyone know why I need to do this? Is it just that the iPhone assumes that loaded views are 300x480 unless a transform gets applied to them? Thanks. ps. This is what the view looks like if I don't call setFrame, as described above: All viewcontrollers that get loaded after the first one will have their screen similarly squeezed down. For some reason the first viewcontroller doesn't have this issue.

    Read the article

  • UIScrollView works as expected but scrollRectToVisible: does nothing

    - by mahboudz
    HI. I have used UIScrollView before, and am using it now, and never had a problem. I'm now adding it to an old app, and while it works as expected (I can look at the contents, scroll around with my finger, all the bounds and sizes are setup right so there is no empty space in the content, etc.), I just can't get scrollToRectVisible to work. I have even simplified the call so that it merely moves to the 0,0 position: [scrollView scrollRectToVisible:CGRectMake(0, 0, 10, 10) animated:YES]; or move it to 0,200: [scrollView scrollRectToVisible:CGRectMake(0, 200, 10, 10) animated:YES]; I even made a quick app to test this and I can get scrollRectToVisible to work there as I expect. But in my old app, I can't seem to make it do anything. I can make the scrollView scroll with setContentOffset:, but that's not what I want. This scrollView and its contents are defined in the nib by IB and used with an IBOutlet. The only code I am using in my app to handle the scrollView is [scrollView setContentSize:CGSizeMake(scrollView.contentSize.width, imageView.frame.size.height)]; (I'm only interested in vertical scrolling not horizontal). Has anyone run into a problem like this? I have compared the scrollView attributes in both apps and they are identical. ADDENDUM: My scrollViews frame is: 0.000000 0.000000 480.000000 179.000000 My scrollViews contentSize is: 0.000000 324.000000 It still acts like the rect I want to scroll to is already visible and no scrolling is needed. Not sure if that is what is happening. This is just the darnest thing. Seems like such an easy thing to resolve... ADDENDUM #2: This is how I am making do without scrollRectToVisible: CGPoint point = myRect.origin; if (![clefScrollView pointInside:point withEvent:nil]) { point.x = 0; if (point.y > clefScrollView.contentSize.height - clefScrollView.bounds.size.height) point.y = clefScrollView.contentSize.height - clefScrollView.bounds.size.height; [clefScrollView setContentOffset:point animated: YES]; } Everything else about this scrollView works as expected, but scrollRectToVisible. WHY?!? Any wild guesses?

    Read the article

  • iPhone: CPU power to do DSP/Fourier transform/frequency domain?

    - by mahboudz
    I want to analyze MIC audio on an ongoing basis (not just a snipper or prerecorded sample), and display frequency graph and filter out certain aspects of the audio. Is the iPhone powerful enough for that? I suspect the answer is a yes, given the Google and iPhone voice recognition, Shazaam and other music recognition apps, and guitar tuner apps out there. However, I don't know what limitations I'll have to deal with. Anyone play around with this area?

    Read the article

  • [iphone] UIControlEventTouchDragEnter doesn't seem to work for catching a tap that slides into a con

    - by mahboudz
    I wanted to allow for a method to get called, if a finger was dragged from outside into the bounds of a control. I thought UIControlEventTouchDragEnter would do it, but it doesn't seem to. Does anyone know if there is a way to trigger an action based on a tap sliding into a control? This is what I was trying, but got no calls to my -fingerSlidIn: [aButton addTarget:self action:@selector(fingerSlidIn:withEvent: ) forControlEvents: UIControlEventTouchDragEnter]; Thanks!

    Read the article

  • Landscape-only orientation + view controllers: What am I still missing?

    - by mahboudz
    Hi. I can't believe I am still having problems with screen orientation, now on the iPad. This is an app that only supports one of the two landscape orientation. In my info.plist, I include: <string>UIInterfaceOrientationLandscapeRight</string> <string>UIInterfaceOrientationLandscapeLeft</string> In Interface Builder, all my views are created in landscape orientation. Only the main Window is not, but I don't see a way to change that. When launched, I get the following coordinates for my main window and the main viewcontroller view: Window frame {{0, 0}, {768, 1024}} mainView frame {{0, 0}, {748, 1024}} (Changing the frame at runtime to be what I expect, does not change the odd behavior.) All other views after that show these coordinates when summoned (when loaded but before being presented): frame of keysig {{0, 0}, {1024, 768}} frame of instrumentSelect {{20, 0}, {1024, 768}} frame of settings {{0, 0}, {467, 300}} In all my viewControllers, i respond to shouldAutorotateToInterfaceOrientation with: return ((interfaceOrientation == UIInterfaceOrientationLandscapeLeft) || (interfaceOrientation == UIInterfaceOrientationLandscapeRight)); In my app, everything (almost) functions as expected. The app launches into one of the two landscape modes. The views (and viewcontrollers) display everything where it belongs, taps work all across the screen, as expected. However, there are two clues that something is still wrong. Clue #1: I have two viewcontrollers that are UITabeViewControllers. When summoned, they are supposed to open up their views and scroll to the selected row of the table. However it is evident that they scroll, but they don't scroll down far enough. It seems that they think that the screen extends further down and they scroll just enough to move the row to a place near the bottom of the screen, but that location is not visible. When the views are loaded, the coordinates are: frame of keysig {{0, 0}, {1024, 768}} frame of instrumentSelect {{20, 0}, {1024, 768}} When I present them using a popover, the frames get resized to: frame of keysig {{0, 0}, {320, 655}} frame of instrumentSelect {{0, 0}, {320, 655}} The frame of the viewController that does the presentation, same mainView frame mentioned above is: frame of self {{20, 0}, {748, 1024}} I have also tried to accomplish the same thing with presentModalViewController instead of presentPopover, and have the same results. This is what the popovers look like: In both cases, the selected row is below the horizon, even though the tableView did visibly scroll in order to make the row visible. I am not sure what to try next. I checked each UITable's scrollView content coordinates and they seemed reasonable. It almost seems like a UITable internal rect gets created with the wrong number and stays that way. Clue #2: All my actionsheets come up with a width of 320. I can only assume that the iPad allows actionSheets in only 320 or 480 widths and since it somehow thinks that the screen is oriented in portrait mode, and then uses the narrower width. There you have it. I can't believe I am still getting hung up on orientation issues. I swear Apple doesn't make it easy to have a landscape app. Any ideas?

    Read the article

1