As per my understanding the WaitForInputAllowed method, will wait for a certain amount of time(30000 ms). This will ensure that the controls get created.
Instead, you use the IsCreated property of an object to see if it is matched at a specific point in time. Along with this you define a looping logic, that will check if the control is created, if it is created it will proceed, if not it will take the else path and retry again.
We faced exactly same issue, and the use of isCreated saved us. Hope this helps.
It would help to see a screenshot of your automation. Generally speaking, the way I prefer to navigate between text adapter screens is to use the NewScreenShowing event. I wait for this event and use the "Setup" of the WaitForEvent to trigger the keystroke that changes the screen. The WaitForInputAllowed is really used only for scenarios where you have a screen that is basically blocked until something else happens. In my experience, this isn't very common.
You'll know when you need the WaitForInputAllowed based on automation errors telling you the field is not editable or something to that effect.
It doesn't sound like you are waiting for the right event to navigate between screens then. I would suggest writing the NewScreenShowing event to a ListBox on screen so you can see when it happens. You can then navigate manually and that would tell you if you can wait for it or not. I don't follow your explanation of why you cannot use it, but if you can test it for yourself, I am betting you'll see enough information to determine where it would be appropriate. Its usage is in places where you might navigate from Screen A to Screen A (back to itself) as there's no other event you can really wait for in that case.