[MacLoggerContest] MacLoggerDX V5 for Cocoa Contest Helper

[Don Agro]

Hi Jonathan,

On 19-02-2009, at 5:03 PM, Jonathan G0DVJ wrote:


> I'm sure that a quick audio discussion on iChat would resolve some  

> of these queries quicker than the 20 or so emails flowing back and  

> forth but not sure that fits the logistics of you both ... happy to  

> bend to fit tho


It's probably best to keep it on the contest list to get as much  
feedback as possible.


> On Feb 19, 2009, at 8:52 pm, Don Agro wrote:

>>

>> On 19-02-2009, at 3:26 PM, David Ferrington, M0XDF wrote:

>>

>>> Current Band - really killer feature; need to have, low on scale

>>> Being able to choose the band in the contest helper pop-up is  

>>> probably the significant issue. Some contests allow dup QSO's on a  

>>> different mode/band - ie in multi-band contests. So being able to  

>>> choose if a dupe is per date or per date AND band is important -  

>>> doing so automatically based on current band would be a very good  

>>> feature, but picking it by hand is ok in my book.

>

> OK but I'm thinking about all those comments that people made  

> telling me that some folk contesting solid for >24 hours cant  

> remember their own name necessarily so we shouldn't assume things  

> etc.   I am afraid I would forget to change the drop down in the  

> contest helper every time I change band and hence the dupe  

> indication would be worthless.  That's the only reason I suggested  

> automatically offering "current band" ... I had no idea that it  

> wasn't simple to do ... sorry - to clarify when I said make the drop  

> down simpler I merely meant aesthetically having 2 entries instead  

> of each band plus all!  I didn't mean to second guess how easy or  

> difficult it is to program - Don's the expert there ... what he says  

> goes!


It's in Beta 10.


>>> David and I are almost agreeing here I think!  That typical  

>>> response is almost right - what I want to be able to give...  

>>> except that it is received serial not sent which is most useful in  

>>> convincing the other guy that we have indeed already worked ...  

>>> Telling him what serial you gave him yesterday at 23:58 doesn't  

>>> help him find (and possibly correct) your call in his log.   

>>> Instead saying "we worked yesterday at 23:58 - you gave me 106"  

>>> immediately lets him look in his log at QSO 106 and check the call  

>>> recorded then against your call now.  Hence my asking for received  

>>> and not sent number.


OK, well they are both in beta 10


> Agree with David ...  It is NOT necessary to display received string  

> - just number.


OK, no strings in beta 10, just tx and rx sn.


>>> Do you want both received serial number and sent serial number ?

>

> No - as above.  If he copied my number wrong and my call wrong then  

> its not a QSO !!!  I would just work the dupe again.


They are both there in Beta 10 - move the one you are not interested  
in off to the right.


>> Rewriting the duplicate list data source to display dates as  

>> "Yesterday" instead of the date is not trivial.

>> You can set the date controller at the start of the contest to show  

>> nothing before the start of the contest and that is remembered in  

>> the Prefs so you are only dealing with one or two dates.

>

> Ok - again didn't know what the complexity is - just noticed that  

> Apple often code things to substitute Yesterday and Today rather  

> than actual dates in finder windows in details view for example.    

> In the case of dupes ... contests only last max 48 hours so it can  

> only be one of two days max.  And rather than remembering the date  

> in the heat of it all, I just thought reading it and saying as David  

> suggested "We worked yesterday/today at ..." would be simpler for  

> the operator than mentally thinking and saying the relevant word.   

> However this is not a big deal at all ... I can manage the mental  

> work!


There will only be one or two dates displayed if you set the date  
picker at the start of the contest.


> If the others have that use it have time to click and populate it  

> fine .. I don't (when working 6Qs a minute) - its no big deal if the  

> facility stays but I David and I need not use it.  I wouldn't use  

> the lookup feature in the contest helper window so to answer your  

> question I guess always inactive.


The Prefs will keep them set to whatever you like.


> Let me try another example on the Dupe thing to see if it is easier  

> to explain how it would help the operator most  (but yes I agree  

> that exact match is required for dupe)...

>

> I type G0A (Dupe window shows nothing unless I have worked short  

> call G0A) .. I continue typing B (Dupe window still shows nothing  

> unless I have worked G0AB - unlikely as 2 letter suffixes with G0  

> prefix were never issued!) ... I continue to type C and the Dupe  

> window stays empty unless I have worked G0ABC, subject to the date  

> and band criteria already set.  If I have worked him on other bands  

> within the time/date criteria ideally it would show in normal  

> colour.  If I have worked him on the band I am on (assuming I have  

> set the band drop down correctly or current is implemented) it  

> should show highlighted in the list (dare I mention red?)  to  

> immediately tell me NOT to work him again.

> I dont care if he calls me as G0ABC/P or /A or anything ... if it is  

> the same station on the same band (or different band depending on  

> contest) I don't want him again.  This is similarly true in the  

> unlikely case that he crosses the border into Wales and calls me as  

> GW0ABC ... he's still a dupe!


Beta 10 will find the typed string in any position for both call  
completion and dupes. I don't think it will be a problem.

73 Don Agro VE3VRW