ARC536: Problems with Butel ARC536 Pro build 2.7

[JvdK]

After updating to Butel ARC536 PRO version 2.7 build 2, I’m experiencing problems with this software. Whatever frequency I enter, ARC 536 Pro changes it to 1300.000000. whatever I do, using dots, comma’s, old FL, new FL , old system, new system, using the TAB key, using the arrow keys, entering the 2 registration key’s again, it doesn’t help 😳. FYI, I have Butel ARC536 Pro installed on a WIN11 laptop to program my UBCD3600XLT.

Does anybody have a solution (other then change to Proscan 😁)?

 

[Ubbe]

Does anybody have a solution (other then change to Proscan 😁)?

When you get 1300 it is the highest frequency allowed and the program interprets the number you enter as being higher than that. Just enter the MHz digits and try both with and without a dot and try a comma as well, not entering any KHz digits. I probably reads all your digits as MHz without reqognising the separator character you are using as KHz. Did you change the decimal character in Windows regional settings from a comma to a dot?

Try reading your scanner and see what it says for the frequencies.

/Ubbe

 

[Butelsoftware]

In Windows set your decimal character to a dot, that should fix your issue. We did add some extra freq rounding code that does not like comma as a decimal character.

Gommert
www.butelsoftware.com

 

[JvdK]

Thanks @Ubbe and @Butelsoftware. After changing the decimal character in Regional Settings ARC536 is working fine again 👍😊

 

[Scan125]

Regional settings can cause problems especially with numerical decimal and thousands characters.

In my software (eg. Scan125) I force the program only (not the whole PC) to use the EN-GB

In VB

Public scan125_culture As String = "en-GB" 'we work in en-UK
'We always run in en-GB local mode
System.Threading.Thread.CurrentThread.Name = "MainThread"
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(scan125_culture)

This ensures that other programs (eg. Excel) that might be using a ',' as a decimal place separator are not changed as well.

The perfect/ideal solution is of course for one's program to naturally use the PC's culture/regional settings HOWEVER the attached hardware (e.g. Uniden scanner) will/could be using a fixed nnnn.nnnn format. Changing the program's culture to match the hardware culture is far easier and safer that in program changing and manipulating '.'s as ','s and ','s as '.'s.

For sure full international country languages and cultures are quite difficult to program/cater for some when a piece of hardware/software as say a "French" or "German" language setting but then uses nnnn.nnnn instead of nnnn,nnnn we have to code a hack. Certainly not ideal but really no other alternative other than to get the hardware manufacturer to correctly and fully support the country's culture.

 

[ProScan]

Regional settings can cause problems especially with numerical decimal and thousands characters.

In my software (eg. Scan125) I force the program only (not the whole PC) to use the EN-GB

In VB

Public scan125_culture As String = "en-GB" 'we work in en-UK
'We always run in en-GB local mode
System.Threading.Thread.CurrentThread.Name = "MainThread"
System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(scan125_culture)

This ensures that other programs (eg. Excel) that might be using a ',' as a decimal place separator are not changed as well.

The perfect/ideal solution is of course for one's program to naturally use the PC's culture/regional settings HOWEVER the attached hardware (e.g. Uniden scanner) will/could be using a fixed nnnn.nnnn format. Changing the program's culture to match the hardware culture is far easier and safer that in program changing and manipulating '.'s as ','s and ','s as '.'s.

My program uses:
Application.CurrentCulture = CultureInfo.InvariantCulture
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture

27% of users are International and I never seen a problem with the decimal (or date).

 

[Scan125]

My program uses:
Application.CurrentCulture = CultureInfo.InvariantCulture
Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture

27% of users are International and I never seen a problem with the decimal (or date).

Thanks for that ProScan.

I was aware of Invariant.

When I originally wrote (say Scan125 for the UBC125XLT) this was for the UK 125 variant sold in the UK and EU as opposed to the US 125AT.

With that in mind and ignoring language we in the EU were working with dd/mm/yy and n.n. The EN-GB local covered the dd/mm/yy and n.n for all EU countries. My program also created/handled UK/EU date/time formats. Also EN-GB did not screw up/mess with EN-US as far as language and number formats.

I'll have a look into using InvarientCulture but I'm a little concerned that for UK/EU dominant usage, especially with created files with dates and times there may be some issues that so far none of my users have raised with the EN-GB locale.

Sometimes I wonder why I privately started writing programs for more general consumption/use

 

[zac]

im using the pro also and it will not let me upload any counties on it. it will show the state list but will not let me click on any county to upload info.