Bill, >> While you are on a roll, I’ll just mention another wish-list item. We >> already have a Tx Next button — it would be nice to have a Next Band >> selector that would override the band-picking algorithm. This could just be >> a box with up-down arrow to cycle through the bands… This could be active in >> both hopping _and_ non-hopping modes. > Couldn't this be achieved by simply selecting a different band from the > main window drop down? We would have to define what that meant when > hopping is active, for example it could disable hopping or it could use > the selected band for one period then return to the normal schedule. What I had in mind was to relieve the user from trying to time the band-change to the 8 second (or so) interval in between receive or transmit periods so that we don’t “waste” a period when changing bands. The Next Band option would essentially queue up the next band, use it for one period, then return to the normal schedule.
I don’t see why we couldn’t implement this behavior using the main window drop down. Would it make sense to change the behavior of the drop-down between hopping and non-hopping mode? In hopping mode, choosing a band from the drop-down would queue up the next band to hop to, whereas in non-hopping mode it would just do what it does now… Here’s the scenario that I have in mind: while hopping among the “Day” bands, you hear a comment on the local repeater that says that 6m is open to VE3 (that just happened here) - so I’d like to check 6m as the “Next Band” so that I visit 6m once, then return to normal hopping. Or would this behavior just confuse the heck out of people who are using the program for the first time. Feel free to tell me that it’s just too complicated. Also, I’ll note that currently, selecting a band from the drop-down bypasses the call to user_hardware. My earlier suggestion on this was to make the user_hardware call an atomic part of any band change. But I have to admit that I don’t understand what implications this might have for the other modes. Steve k9an > 73 > Bill > G4WJS. > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel