Hi Brendan, Na, we haven't forgotten but most of the things you ask for are major development efforts and so I can't promise what gets done or not done. Will just have to see where things go as we work through the various modules.
Thanks, Jack ----- Original Message ----- From: "Brendan Minish" <[EMAIL PROTECTED]> To: "Jack" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, January 08, 2003 9:01 PM Subject: Re: [DXBase] Wish List items > At 17:03 08/01/2003 -0500, Jack wrote: > >Hi Ron, > > > >I'll pass these along to the developers. I know they have been hard at work > >for several weeks now and don't know how much "extra" development time > >remains available for this cycle. > > > Seeing as there is another version in the offing perhaps I could trouble > you with a reminder of the various requests I have made over the last year > or so > > these are simply cut 'n paste from previous E-mails so there may be some > duplication and more than a little disorganization to this list but I hope > they provide food for thought. > > > 1 biggie though > > the grid square feature should always treat 4 figure grids as a subset of 6 > figure grids, for instance searching for IO53 does not correctly cross > reference with entries that have 6 figures such as IO53hu. > A search for IO53 will never find IO53hu > This is unworkable for the 6m operator which is why I ADIF export my vhf > logs to VQlog for proper manipulation. > www.vqlog.com > > At the bottom of this list is a repeat of my request for a much improved > radios.ini file and rig support, this will, I feel make life easier for all > in the long run, currently rig support seems to be added by us the users > and giving us better (i.e more flexible ) tools to do this with can only be > a good thing for DXB2004 as it gives DB the edge over the competition (Who > are also suffering form changing interface standards from radio > manufacturers) thanks to superior radio support. > > > 1/ Spot filtering. Spot filtering should not filter repeat spots for a Call > sign IF originating Call is different. > > E.g Dx de G7CUW : 50120 VK2MS > and > DX de EI4IZ: 50120 VK2MS > > should both appear in the dx info window instead of just the first spot. > > 2/ Cut and paste between windows should work much more efficiently. for > example it should be possible to cut and paste address info into DXbase > after doing a QRZ search (which after all DXbase supports from the > toolbar). Currently you can only paste address info line by line. > It would be great to be able to copy and paste info from the QSL Info > window into the log (E.G grid squares. > > 3/ CD rom lookup needs to be more intelligent, eg. EI7IQ produces a valid > lookup whereas EI7IQ/P does not. EA8/EI7IQ fills in the details on CD rom > for the EA8 buero, Not helpful.. EA8/EI7IQ shoud take name and QSL info > from EI7IQ burt leave grid QTH and county blank 9as he is operating EA8/ > EI7IQ/m (or p or / anything else ) should be treated the same way > > 4/ Whilst it is nice to be able to resize the rows in all the windows it > should be possible to lock them to a certain size as resizing by accident > is a big problem. > > 5/ deleting records does not work reliably using the delete key, the menu > option works fine, this is due to selection not always being straightforward > > 6/ DX spots really ought to expire after a set time interval, I know > emptying the DX info window works but it would be better if spots could be > configured to expire after a user configurable period of time. old spots > are not useful to anyone. > > 7/ packet window should not open automatically at startup IF there is no > TNC configured, it should be possible to configure an auto connect > at start up for both / either the packet and Internet clusters as a option > if required > > 8/ summary window should always give the bearing based on the grid square > IF the grid is available in the QSL info, It already does this when in VHF > grids mode,so do the same in the other modes IF the grid is available and > the call is not ??/ or /?? I.e vk/ei6iz or ei6iz/m > > 9/ the incoming DX cluster (& Internet cluster ) should accept data in more > than one format, I .e spots come in as > > DX de EI4IZ: 50120 VK2MS > but if I do a SH/DX spots are in a different format > > 1822.4 HK4CZE 9-Jan-2003 0137Z <K9DX> > > It would be nice to be able to use the spots from a SH/DX comand (many > clusters including my own will do a SH/DX/10 when you log in ) to populate > the dx column > > 10/ ability to populate log entries with information from CD database after > the contact has been logged > > 12/ It would be nice to be able to set the log window to be always on top' > for those pileup situations > > 13/ If you enter a call DXbase does a CD rom lookup and enters the results > into the log (which is good) however if you change the callsign again > because of a typo etc a new lookup isn't done but the call changes, a new > lookup should be done IF that contact hadn't been logged (I.e Entered into > the database by using the down arrow, Mousing onto the next row or using > the enter key) > > Grids in previous QSO's window > lookup by partial grids E.g EL98 should produce a list of all qsos > with EL98 whereas EL98HK shows only qsos with EL98HK > partial call lookup would be nice as well E.g EI7 should list all > EI7 s worked. > > TNC interface > ability to interface with the AGWpacket engine > 1/ Some of us are using this software to connect more than one > application to 1 TNC > 2/ some are using it to get on packet with just a sound card. > 3/ it provides an excellent interface for the Bayom TNC (which has > no command interface) or the various cheap KISS only TNC types. > > the programmer makes everything needed available for 3rd party software > support > http://www.elcom.gr/sv2agw/ > Roger Barker (author of UIview ) also has good info on AGW > http://www.ui-view.com/ > > > TNC interface > Proper scripting support for things like the Kenwood TMD700. > > > Cluster > > 1/ Please stop the tnc window loading if the TNC isn't enabled > 2/ Allow for automatic internet cluster logon for those of us who have > always on Internet (or are running a cluster on the local network ;-) > > DXinfo window > > More flexible filtering please. > it would be just heaven if for example I could allow ALL 6m spots > to appear in the DX info window along with only the HF spots I need > > Wild card filtering by call sign E.g EI* in the call sign alerts list > should be permitted, more call sign alert slots. > > Always replace an old spot in the dxwindow with a newer spot for the same > station. > > An expire time option, > spots are pretty useless once they are older than a certain period of time > so discard old spots from the dxinfo pane, time to be configurable by the > user, set to 0 for current behavior > > > Fonts and things. > if I use the zoom tool it would be nice if DXB remembered this for > the next time I open the program. > I can't seem to change the font size for the QSL info pane > It would be nice to be able to make global font changes sometimes > > I would LOVE to be able to 'lock' the resize all rows ' feature' as I am > always accidentally resizing rows when trying to select a single row, > resizing not something that I actually want to do very often. > I would also love to be able to lock out the 1 click sort that I do from > time to time when I click on a column header, perhaps make sort and resize > right click items? > > bands and modes > > It would be really nice to be able to Hide bands, modes, QSL > routes etc that don't ever get used by me from the various pull down menus. > > I want to hide the following, all modes except SSB,CW,FM,Pactor. all bands > above 70Cm and 222 Mhz which we don't have. all qsl routes except none, > Buro, Manager. > > Add JT44 and JT441 as modes (6m & 2m Meteor scatter modes ) allow user > defined modes ?? > > > Radio interface. > The new mute function is good but I still have to disable the > radio control port when I want to use some of my pactor software as it > expects (& I want it to) to be able to control the radio directly. > It would be nice if the options menu remembered which pane was > open last time. > how about providing a virtual com port which would allow other > software to pass commands to and from the radio through DXB? > > > Summary window > A redesign to use less screen area might be worth considering > > Possible BUGS with 2003. > > Dxinfo pane > possible bug, I cant hide columns I don't want, I can only make > them very narrow. > > Radio not responding error > Still present I am afraid with my ICOM radio, very infrequent with > driver X disabled, quite frequent with driver X enabled. Now using a > different Win2k machine (faster CPU, different Motherboard etc ) and a > different radio (756PRO2) but noticed no difference in the frequency of > this error. > I am willing to work with you on this one, perhaps a DXB2003 EXE that is > compiled to log all radio data both ways & I can then send you the logs. I > have not had any problems with other software and radio control, just DXB. > > > > New features > > How about a Split screen terminal built in that can be configured on a > separate or the same com port as the packet (but in this case can only be > opened if the DXcluster connection via packet is closed) That can be used > for keyboard modes with A TNC or multimode modem such as the SCS-PTC > modems. include some user defined keys and a few memories for brag sheets, > common commands etc. > Include a simple log interface (e.g point and click on a call to log the call) > > Logging interface > How about adding an interface like that of VQ log (& many others) for > logging. Allow the user to define which fields need filling which would > make moving around this new interface using TAB and arrow keys very quick. > > E.g when working 6m pileups all I want to enter is > Call RSTs RSTr GRID. I expect the software to get the frequency & mode from > the radio and tentatively fill in the Grid from the callbook or past qso's > this would provide a less cluttered interface for entering lots of contacts > Allow the user to save multiple setups of this interface, e.g 1 for 6m 1 > for Hf CW etc. > > perhaps this new interface could be done as an expansion of the contest mode. > > > Since it would appear that support for new radios is actually added in most > cases by the users, not Scientific solutions and the protocols used by > various radios constantly changing when new models come out, It Seems to me > that future versions of DXB could do more to make the job of adding support > for future radios easier to do and allow for some improvements to existing > radios. > > Here are my suggestions for some improvements, most of these appeared > initially as part of the TS2000 thread > > DXB does a better job than most with the radios.ini file approach and I am > happy to write a new entry if I am the first user with a particular radio > as I have done with the K2. I am also happy to share this file with other > users. > > What I would like to see from the software authors is more control over > what one can do in the radios.ini file. > > > Such as. > > Error handling (for radio OR software errors) > > Ability to code in some of the serial port parameters I.e some radios only > support certain baud rates (or even have 1 fixed baud rate) and require > certain parity and stop bit settings, obviously the com port # need not be > coded into the .ini file! this would make it easier for the end user it > would provide less room for error by removing the settings that won't work. > If there are no com port parameters set then all possible options are > available like now > > PORT_SPEED = 4800,9600,19200 (means that user can only select from these > values) > PORT_PARITY= NONE (or EVEN ODD etc) > PORT_BIT= 8 (or 7 etc) > PORT_STOP=1 (or 0,1,2 etc ) > PORT_HANDSHAKE = Hard (or NONE or CWKEY (to allow the same com port for CW > keying by means of the RTS or DTR lines) ) > > An option to force DXB to write a logfile of all data sent to and from the > radio for debugging when making changes to the radios.ini file > > Support for extended modes (I.e CW-R etc) which simply would involve DXB > accepting more than one value as a response for a mode query. > > Ability (where available ) to make use of information concerning which VFO > is active. > > An understanding of Dual watch as well as split. (optionally treat the same > as split ) > > The ability (where the radio supports it ) to key CW by sending the > appropriate ASCII strings to the radio (kenwood TS2000, elecraft K2 and > probably other recent kenwoods ) along with other support required for this > feature. > > It would be important to be able to specify the order in which commands are > used. These changes would require the radios.ini file to undergo an overall > rewrite. but since most radio files work as they are this would be a fairly > trivial issue of adding a generic extra bit to each of the existing > entries. (or even just assuming a generic order where not otherwise defined > ) Therefore it should be possible to add these new features breaking ay > existing ones > > I propose that the radios.ini format continues to define each command > EXACTLY as is now done and adds support for any user defined commands that > may be required in the future or to handle certain special features. > > After the commands are defined, the strings sent (action definitions) along > with any additional pauses for replies etc for each action in DXB can be > defined. > > Action definitions should only allow use of the predefined commands (to > stop things getting messy, don't forget the support for user defined > commands!) and the built in timing commands such as eoc(100) > > CLICKSPOT = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO, > SETVFOA, SETmodeA, SETVFOB, SETmodeB, SETsplit > > READ_LOG = GETvfoa, GETmodeA, GETvfob, GETModeB,GetSplit, GetActiveVFO > > you get the idea > > followed by error handling entries > > RETRIES = 3 <-how many retries before annoying the user with an error > message WHATEVER the cause of the error. > RETRY_WAIT = 200 <-how many msec to wait before repeating the command when > retrying > > followed by the debug options > ERROR_LOG = 0 > > 0= no log, 1 only log errors or retires (including the previously sent > string), 3 log everything in from rig, 4 log everything out, 5 log all commands > put an extra <CR> after each response from the radio to make things easier > to read > > LOGFORMAT = HEX (or ASCII ) > > LOGFILENAME = whatever.txt (saved in the DXB directory ) > > In the absence of any of these new features from a particular entry in the > INI file DXB could assume the current default behavior to ensure 100% > backward compatibility with older radios.ini files. > > The DXB help file would need more information added on how the radios.ini > file works as well.. > > > regards > Brendan EI6IZ >
