On Saturday 18 July 2009 20:01:36 Dirk Bartley wrote: > On Sat, 2009-07-18 at 18:51 +0200, Kern Sibbald wrote: > > Hello Dirk, > > > > I have analysed the problem of bat getting confused when the Director > > sends an unexpected PROMPT -- in fact, as far as I can see, it is > > probably any prompt that is not the MAIN_PROMPT or a PROMPT after a START > > SELECT. > > > > In most cases, such as a START SELECT, you go into a special dialog > > handler, which then reads all the input lines, and responds to the > > Directory. > > What I have not figured out yet is how to create the condition for when > a text box would be required. I'll either have to create a new variable > in the dircomm class for in a select, .. .. or you'd have to send a > different signal for CASE BNET_PROMPT_TEXT_USER_INPUT.
I think the information is already there. If some dialog such as a select is handling all input when a BNET_PROMPT arrives, then m_notifier->isEnabled() is false. If the notifier is enabled (true), then there is no one handling input, and everything breaks because a new conn is used when the user completes the input in the command box and input_line() in winmain.cpp is called. If input_line() used the current conn when calling consoleCommand() then everything would work correctly (I think). It seems to me that the input_line() routine should only get a new conn if the notifier is disabled, because you don't want user command input to interfere with any current dialog. Or alternatively, as you say, at a lower level, you can call a new dialog handler in the BNET_PROMPT routine when the notifier is enabled. Regards, Kern > > I'll proceed assuming that the first would be best. > > Dirk > > > In the case of a PROMPT not following a START SELECT, bat is in a wait > > state and when the user enters a response in the command line a > > notification will come in and ultimately call input_line(), which wll > > call consoleCommand() in the Pager, and that is where everything goes > > wrong, because consoleCommand() will then choose any available conn > > connection to send the user's response, rather than the conn that was > > where the original PROMPT originated. Bottom line: a prompt request > > comes in on conn=0 and the user's response will be sent out on conn=1, > > which of course does not work. > > > > So, either we need some default handler for a PROMPT, or some other > > solution, and unfortunately, I don't know how the m_conn stuff is handled > > well enough to work out a solution. > > > > Best regards, > > > > Kern > > > > ------------------------------------------------------------------------- > >----- Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to BlackBerry App World(TM) will have > > the opportunity to enter the BlackBerry Developer Challenge. See full > > prize details at: http://p.sf.net/sfu/Challenge > > _______________________________________________ > > Bacula-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
