[MacLoggerContest] MacLoggerDX V5 for Cocoa Contest Helper

[Don Agro]

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.

>

> Having said that, I also would have though it was a reasonable  

> simple thing yo do - get current band from main window - apply to  

> band displayed in Contest helper.

> Obviously it's not as simple as one would have thought - why?


The Contest Data Source is not connected to the radio, it would have  
to query the Radio Controller object through the application delegate.  
This would also add to the CPU load for each item in the log as they  
are tested in real time for the search criteria each time a key is  
pressed in the Contest call sign text field.


> As I understand it (I haven't yet done a contest that spans > 24hrs  

> or goes over midnight) what we are  looking for is an indication of  

> when the contact was previously made. THis would normally be up to  

> 48 hrs ago on a lomg weekend contest.

>

> Don't assume that 36 hrs into a contest with perhaps no sleep, the  

> op is capable of a lot of stimulant thought - I would think at that  

> point the sub-neural has cut in and everything is working by  

> remembered reflex :-)

>

> Don't assume the operator remembers their own name, that's alone  

> what day it is!

>

> Time-on and Serial number is what is required, typical response is  

> "we worked yesterday at 23:58, I gave you 1234". received string  

> probably not required.


But Jonathan specifically asked for received serial number :

On 19-02-2009, at 2:04 PM, Jonathan G0DVJ wrote:


> 2) When a dupe is found it is useful to display a table of band,  

> date (Today or Yesterday is sufficient), time and serial number  

> received (where applicable)


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

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.


>>> 4) I don't think I would ever use the 2 check boxes provided  

>>> Lookup & Display QSO.   Others might I suppose (David?) but I  

>>> would skip them.

>>

>> Does that mean you want them always active or always inactive ?

> I don't use them currently, it takes too much time (yes it's only a  

> second or so, but that is too long). I leave look-up off (QRZ  

> subscribed).

> However, clearly some ops do use look-up and I guess that look-up  

> via a CDRom or disk list is fast and therefore not a problem.

>

> So just what does the 'Look Up' check box on the Contest Helper  

> enable?


In the K5ZD list it does a full lookup on the call.
In the Duplicates List it displays the QSO from your log.



>> OK, so we never need to restrict it to the start of the call for  

>> SCP, but we do for the dupes ? or we don't ?

> Dupes must be exact match in my book - you can only test for a dupe  

> when you've got the exact call. Even a single letter difference  

> means its not a dupe.


What about a different prefix or suffix - do they never change during  
a contest ?

At any rate if you type in enough letters you will by definition be  
getting an exact match - try it.

73 Don Agro VE3VRW