Hi Colin.
There appears to be a small buglet in the data entry screen with reference to the PWR field. I presume the current design assumes that the power is entered in Watts, but my logs are all in dBW instead, and this is what has shown the bug up.
At one stage, I was operating with power levels of 500mW (0.5 W) which corresponds to -3 dBW. As a result, I entered the value -3 in...
Options => Options => Custom Lists => Add Pwr
...and, after I had done so, WinLog32 skipped the PWR field in the data entry screen and always entered the value 0 therein, preventing me from entering anything at all in that field.
I presume that the presence of a - sign as the first character of the first value in that list is being used as a flag to indicate that the list is empty, or something along those lines. However, such is obviously not a good choice for this field.
Best wishes from Riley G7GOD / KB8PPG
Bug in PWR field
Bug in PWR field
Hi Riley
Yes you are corect values of 0 of less are automatically skipped, as originally this was a simple switch to disable this field (user requirement).
In v2 I am looking for a new switch which give the appropriate action but allowing dbW of 0 or less to be entered.
73 Colin G0CUZ
Winlog32 Author
Yes you are corect values of 0 of less are automatically skipped, as originally this was a simple switch to disable this field (user requirement).
In v2 I am looking for a new switch which give the appropriate action but allowing dbW of 0 or less to be entered.
73 Colin G0CUZ
Winlog32 Author
Bug in PWR field
Hi Colin.
Can I suggest the use of a rather simpler test: If there are no values in a particular list, that list is skipped on the simple basis that it is impossible to choose a value from an empty list. This rule would automatically apply to all lists.
Best wishes from Riley G7GOD / KB8PPG
Can I suggest the use of a rather simpler test: If there are no values in a particular list, that list is skipped on the simple basis that it is impossible to choose a value from an empty list. This rule would automatically apply to all lists.
Best wishes from Riley G7GOD / KB8PPG
Bug in PWR field
Hi Riley.
Your suggestion sounds good to me, I'll be looking at this shortly.
Thanks.
73 Colin G0CUZ
Winlog32 Author
Your suggestion sounds good to me, I'll be looking at this shortly.
Thanks.
73 Colin G0CUZ
Winlog32 Author
Bug in PWR field
Hi Colin.
Related to the above, can I mention another couple of buglets...
In the "Band" list, I have both 144 and 145 entered, as I personally treat those as two separate bands as far as operating is concerned, with 144 for CW/SSB and 145 for FM operating. However, when I switch from one to the other, it always pops the frequency entered for the other in the frequency box when I press the TAB key. However, when I switch to any of the other bands, it always enters the "band" value into the frequency box ready to enter the decimal part thereof.
Personally, I would prefer to see this latter behaviour when one changed the selected entry in the band box to a value that does not correspond to the integral part of the value in the frequency box, so it would change to just the MHz part of the value even on changing between 144 and 145 as values.
The second buglet, related to the above, is in the fact that it leaves one to enter the decimal point in the frequency value every time. I realise that some people don't bother to store the kHz part of the frequency, but I prefer to do so, and I find this particularly niggling.
My suggestion here would be for WinLog to append the dot to the band value ready for the user to append the kHz value, and to simply omit storing it if no kHz were entered.
The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Best wishes from Riley G7GOD / KB8PPG
Edited by - rhw2 on 15/03/2003 6:06:43 PM
Related to the above, can I mention another couple of buglets...
In the "Band" list, I have both 144 and 145 entered, as I personally treat those as two separate bands as far as operating is concerned, with 144 for CW/SSB and 145 for FM operating. However, when I switch from one to the other, it always pops the frequency entered for the other in the frequency box when I press the TAB key. However, when I switch to any of the other bands, it always enters the "band" value into the frequency box ready to enter the decimal part thereof.
Personally, I would prefer to see this latter behaviour when one changed the selected entry in the band box to a value that does not correspond to the integral part of the value in the frequency box, so it would change to just the MHz part of the value even on changing between 144 and 145 as values.
The second buglet, related to the above, is in the fact that it leaves one to enter the decimal point in the frequency value every time. I realise that some people don't bother to store the kHz part of the frequency, but I prefer to do so, and I find this particularly niggling.
My suggestion here would be for WinLog to append the dot to the band value ready for the user to append the kHz value, and to simply omit storing it if no kHz were entered.
The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Best wishes from Riley G7GOD / KB8PPG
Edited by - rhw2 on 15/03/2003 6:06:43 PM
Bug in PWR field
Hi Riley
Thanks for the feedback.
1.
I think you are referring to the fact that the MHz does not change in the frequency box when the Band pre-selector is moved between (say) 144 and 145.
I will look at this, I had not anticipated that it would be used in this way you mention.
2.
About the decimal point, there was a readon for this, I think it was a 'regional' problem (e.g. some use a comma for a decimal point in some regions.
The easiest way around this is to add "144." (include the point) to the band selector.
3.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
73 Colin G0CUZ
Winlog32 Author
Thanks for the feedback.
1.
I think you are referring to the fact that the MHz does not change in the frequency box when the Band pre-selector is moved between (say) 144 and 145.
I will look at this, I had not anticipated that it would be used in this way you mention.
2.
About the decimal point, there was a readon for this, I think it was a 'regional' problem (e.g. some use a comma for a decimal point in some regions.
The easiest way around this is to add "144." (include the point) to the band selector.
3.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
73 Colin G0CUZ
Winlog32 Author
Bug in PWR field
Going back to disabling the power list, having now spent some time on this I can see there are inherent problems with no values entered into the power list, as when restarting Winlog32 re-sets the default list.
For various reasons I do not want to change this action.
So I have decided that to switch off the Power field entry, entering "Off" into the Custom list (power) and when selected the power field is skipped.
This seems logical, allows any power value including negative dbW to be added or alows those users to skip the field if they wish.
73 Colin G0CUZ
Winlog32 Author
For various reasons I do not want to change this action.
So I have decided that to switch off the Power field entry, entering "Off" into the Custom list (power) and when selected the power field is skipped.
This seems logical, allows any power value including negative dbW to be added or alows those users to skip the field if they wish.
73 Colin G0CUZ
Winlog32 Author
Bug in PWR field
Hi Colin.
To deal with your comments one by one, and respecting the message limit in this forum...
quote:quote:In the "Band" list, I have both 144 and 145 entered, as I personally treat those as two separate bands as far as operating is concerned, with 144 for CW/SSB and 145 for FM operating. However, when I switch from one to the other, it always pops the frequency entered for the other in the frequency box when I press the TAB key. However, when I switch to any of the other bands, it always enters the "band" value into the frequency box ready to enter the decimal part thereof.
Personally, I would prefer to see this latter behaviour when one changed the selected entry in the band box to a value that does not correspond to the integral part of the value in the frequency box, so it would change to just the MHz part of the value even on changing between 144 and 145 as values.
I think you are referring to the fact that the MHz does not change in the frequency box when the Band pre-selector is moved between (say) 144 and 145.
I will look at this, I had not anticipated that it would be used in this way you mention.
That would be a fair description of the situation as I see it. Thanks for that.
quote:quote:The second buglet, related to the above, is in the fact that it leaves one to enter the decimal point in the frequency value every time. I realise that some people don't bother to store the kHz part of the frequency, but I prefer to do so, and I find this particularly niggling.
My suggestion here would be for WinLog to append the dot to the band value ready for the user to append the kHz value, and to simply omit storing it if no kHz were entered.
About the decimal point, there was a readon for this, I think it was a 'regional' problem (e.g. some use a comma for a decimal point in some regions. The easiest way around this is to add "144." (include the point) to the band selector.
How does WinLog32 deal with this situation when exporting ADIF files for use with sites like http://www.eqsl.cc for example? Surely such files need to be created independent of any suchlike conventions?
Personally, I would have expected any such issues to be the province of the data entry and data display routines only, with the rest of the system using a single convention for storing data. The data entry/display routines would then be written to take account of the current regionalisation settings in Windows itself.
quote:quote:The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
This is where I run out of message length, so see next comment...
Best wishes from Riley G7GOD / KB8PPG
To deal with your comments one by one, and respecting the message limit in this forum...
quote:quote:In the "Band" list, I have both 144 and 145 entered, as I personally treat those as two separate bands as far as operating is concerned, with 144 for CW/SSB and 145 for FM operating. However, when I switch from one to the other, it always pops the frequency entered for the other in the frequency box when I press the TAB key. However, when I switch to any of the other bands, it always enters the "band" value into the frequency box ready to enter the decimal part thereof.
Personally, I would prefer to see this latter behaviour when one changed the selected entry in the band box to a value that does not correspond to the integral part of the value in the frequency box, so it would change to just the MHz part of the value even on changing between 144 and 145 as values.
I think you are referring to the fact that the MHz does not change in the frequency box when the Band pre-selector is moved between (say) 144 and 145.
I will look at this, I had not anticipated that it would be used in this way you mention.
That would be a fair description of the situation as I see it. Thanks for that.
quote:quote:The second buglet, related to the above, is in the fact that it leaves one to enter the decimal point in the frequency value every time. I realise that some people don't bother to store the kHz part of the frequency, but I prefer to do so, and I find this particularly niggling.
My suggestion here would be for WinLog to append the dot to the band value ready for the user to append the kHz value, and to simply omit storing it if no kHz were entered.
About the decimal point, there was a readon for this, I think it was a 'regional' problem (e.g. some use a comma for a decimal point in some regions. The easiest way around this is to add "144." (include the point) to the band selector.
How does WinLog32 deal with this situation when exporting ADIF files for use with sites like http://www.eqsl.cc for example? Surely such files need to be created independent of any suchlike conventions?
Personally, I would have expected any such issues to be the province of the data entry and data display routines only, with the rest of the system using a single convention for storing data. The data entry/display routines would then be written to take account of the current regionalisation settings in Windows itself.
quote:quote:The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
This is where I run out of message length, so see next comment...
Best wishes from Riley G7GOD / KB8PPG
Bug in PWR field
Hi Colin.
Continuing...
quote:quote:The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
Probably batter design choices would be:
WinLog32 remembers the column widths used for each screen, then the user can drag the columns to the widths (s)he desires and have WinLog32 respect that.
When opening a particular screen, if WinLog32 can't find the desired column widths for that screen, it auto-sizes the columns to use the full width of the screen less the width required for a scroll-bar on the right hand side, which it assumes will be required at some time. This would automatically deal with the screen resolution of the target system.
Also useful here would be the ability to specify the font size to use within WinLog32 as some of the screens are a definite eyestrain on larger display resolutions such as the 1600x1200 that I run on my 19" monitor.
I'll analyse the different screens in separate topics so we can handle the message limit on here...
Best wishes from Riley G7GOD / KB8PPG
Edited by - rhw2 on 21/03/2003 08:32:10 AM
Continuing...
quote:quote:The final buglet I have noticed is in the display of the database "Edit" screens, where the field widths (at least on my system) are far narrower than the data entered into those fields. With the WAB database, this is particularly true of the Authority and Date fields.
Personally, I would suggest that the width of the date field be set sufficient to allow the date 28-May-8888 to be displayed as this has the widest character in each character position. Likewise, time fields should be wide enough to display the value 23:28 for the same reason.
Some of the database edit columns may not be the correct width, many were originally set up with 640x480 in mind when this was definately the norm, if you can let me have specific databases/columns that don't fit I'll certainly change the defaults.
Probably batter design choices would be:
WinLog32 remembers the column widths used for each screen, then the user can drag the columns to the widths (s)he desires and have WinLog32 respect that.
When opening a particular screen, if WinLog32 can't find the desired column widths for that screen, it auto-sizes the columns to use the full width of the screen less the width required for a scroll-bar on the right hand side, which it assumes will be required at some time. This would automatically deal with the screen resolution of the target system.
Also useful here would be the ability to specify the font size to use within WinLog32 as some of the screens are a definite eyestrain on larger display resolutions such as the 1600x1200 that I run on my 19" monitor.
I'll analyse the different screens in separate topics so we can handle the message limit on here...
Best wishes from Riley G7GOD / KB8PPG
Edited by - rhw2 on 21/03/2003 08:32:10 AM