ARC536: Problems with Butel ARC536 Pro build 2.7

JvdK

Member
Joined
Apr 11, 2023
Messages
110
Location
Zeist, The Netherlands
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

Member
Joined
Sep 8, 2006
Messages
9,098
Location
Stockholm, Sweden
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
 

Scan125

Member
Joined
Apr 30, 2014
Messages
572
Location
UK
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.
 
Last edited:

ProScan

Software Provider
Premium Subscriber
Joined
Jul 2, 2006
Messages
7,499
Location
Ontario, Calif.
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).
 
Last edited:

Scan125

Member
Joined
Apr 30, 2014
Messages
572
Location
UK
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 :)
 
Top