Windows 10 Desktop App - Location Services Not Available

Solar2D Win32 Desktop
#1

Greetings,

I have been working in Corona for four years (and loving it, BTW) and have never come across a problem I couldn’t solve one way or another… until now. I have searched high and low for a solution, without success, so this is now my last resort.

I am building (what should be) a very simple cross platform desktop app, for Mac and Windows platforms. It attempts to grab weather data for the current location and display a 7-day forecast. The Mac OS X version works perfectly, both in the Simulator and the standalone executable. Windows 10, however, is exhibiting a behavior that has me stumped.

I am using the following code to first test if location services are available:

if not system.hasEventSource( "location" ) then -- alert that location services are not available else -- set a flag to true so that location can be obtained and weather data downloaded later end

Running in the Simulator on Windows 10, the above code returns ‘true’, and the app grabs the weather data from an external service URL.

After building for Win32, and running the standalone .exe, the above code returns ‘false’ and the alert is displayed. Running the .exe using Corona Output Viewer has the same result - location services are not available. Running the main.lua file from the Corona Shell also has the same result. It is only in the Simulator that location services are available.

I have checked to ensure that location services and are on under my Windows Settings. Location is on, Location Service is on, General Location is on, Default Location is set, and Apps that can use precise location are all on. I have tried turning location services off and on again (insert IT Crowd joke here), I have checked the Windows Registry to ensure that all location services are active. I have tested location services by opening the Windows Maps application, and it detects my exact location perfectly. Everything seems to be fine on the system side.

As far as I can tell, the above code *should* work. It works fine on the Mac OS X desktop version, but not on Windows 10. It works in the Simulator, but not in the standalone .exe or using the Corona Shell or Output Viewer.

As an aside - All my experience with Corona up until now has been on Macs, building iOS and Android games. I used to build for Windows (3.1,95,98,XP) 20+ years ago, but this is my first foray into building desktop apps for Windows 10, so maybe I’m missing some vital setting, although I have done extensive research into all the possible location services settings and potential issues, but I cannot find any information about this specific issue with building a Win 10 desktop app with Corona.

One thing occurred to me is that perhaps this is an issue with the app not having actually been installed - the .exe is being run directly from the folder it was built into. Could Windows be blocking the location services request from the app simply because it hasn’t been ‘officially’ installed via an installer application? However, I would have expected Windows to alert me to this fact when I try to run it.

So that’s my problem. I’ve been coding for 35 years and it is extremely rare that I have to ask for help - I prefer to find solutions myself because it’s a better way to learn - but I’ve been trying to figure this one out for weeks now, and I’m finally at the end of my rope.

Any assistance would be most gratefully accepted!

Many thanks. Niilo.

#2

Can you put together a simple project that can reproduce this and the file a bug report?  The sample project should be something our engineers can just build and run, so it will need a build.settings, config.lua and any assets needed to run. Zip that up and email support@coronalabs.com.

Rob

#3

Hi Rob,

Thank you so much for your quick response. I have sent an email to Support along with a Zip of a bare-bones project that I have confirmed demonstrates this issue, and a link to this thread.

Looking forward to hearing back and finding out exactly what is causing this.

Cheers, Niilo

#4

For desktop builds, generally if it works in the simulator, it should work in the desktop build.

Rob

#5

Yes, and that’s the behavior I would normally expect. I’ve created a slew of games of varying complexity for mobile and rarely do I ever have any problems, and they’re usually resolved by a search here or on the web.

In my experience, Corona is an incredibly solid and stable engine, which is one of the reasons I’ve been using it for so long and I always try and utilize it whenever a mobile game project comes along.  And that’s why this issue feels so out of place, especially with not being able to find any other references to it. It’s an anomaly that, to all intents and purposes, *should* work.

#6

Greetings.

I was wondering if there had been any progress on this issue? I created a shell project which demonstrated the problem and filed a bug report with support.  I know you guys probably have a huge to-do list of stuff that’s far more important than this relatively minor thing that most people wouldn’t even be using, but I would like to get it resolved so that I can finally deliver the app to my client.

Many thanks!

#7

Our engineering team has been busy as we prepare to release a new public release this week and I’m pretty sure they’ve not had time to look at this. But I need to find the bug report and do some investigation on it.  Do you have the Case ID # that would have been emailed back to you?

Rob

#8

Thank you Rob, much appreciated.

Not sure if this is the case #, but it was appended to the subject of the email reply I got: 8162523

Cheers, Niilo

#9

We don’t currently support location services on Windows.

The bug here is that the Simulator is responding to system.hasEventSource( “location” ) with true when it shouldn’t (i.e. the Desktop app’s response is actually correct).  

system.hasEventSource( ) first considers does CoronaSDK support the event source on this platform at all and then it determines whether the current device (or computer) has this functionality.

It seems that when “the app grabs the weather data from an external service URL” it’s making its own arrangements to determine the location and that’s why it works when the Simulator returns the false positive.

Supporting location services on Windows is on our todo list but I have no information on when it might be available.

And Rob is correct to say “generally if it works in the simulator, it should work in the desktop build” and I’m going to be interested to discover why that isn’t the case here.

#10

I’ve determined the source of the confusion.

The Corona Simulator on Windows will synthesize a fake location event for lat/long 37.448485,-122.158911 for testing purposes but Desktop apps, for obvious reasons, don’t do this.

I’ll make sure the documentation includes this information.

#11

Hi Perry,

Thank you very much for taking the time to look into this and letting me know what’s happening.

At least I know it’s not me doing something stupid! :slight_smile:

I guess that my only option right now would be to include a field where the user can enter their zip code manually, and I’ll explain to my client that it would only need to be done once when the app is first run, and when this service is eventually provided I’ll change the code to automate it.

Thanks again - I know this is a somewhat unusual use-case scenario, but I very much appreciate you investigating it.

Cheers, Niilo

#12

If it’s going to run on a laptop of Surface, it may be portable, so you may need to  allow them to change their location.

We did a weather app as a sample:  https://github.com/coronalabs-samples/CoronaWeather and one of the features is the location selection screen which uses a local SQLite location database and uses a native.newTextField to do a search of the DB and show it in a temporary widget.newTableView. You could adapt something like that in your app.

Check it out.

Rob

#13

That’s awesome!

Thank you Rob - I didn’t know about the weather sample. That will help a lot.

Cheers, Niilo

#14

Can you put together a simple project that can reproduce this and the file a bug report?  The sample project should be something our engineers can just build and run, so it will need a build.settings, config.lua and any assets needed to run. Zip that up and email support@coronalabs.com.

Rob

#15

Hi Rob,

Thank you so much for your quick response. I have sent an email to Support along with a Zip of a bare-bones project that I have confirmed demonstrates this issue, and a link to this thread.

Looking forward to hearing back and finding out exactly what is causing this.

Cheers, Niilo

#16

For desktop builds, generally if it works in the simulator, it should work in the desktop build.

Rob

#17

Yes, and that’s the behavior I would normally expect. I’ve created a slew of games of varying complexity for mobile and rarely do I ever have any problems, and they’re usually resolved by a search here or on the web.

In my experience, Corona is an incredibly solid and stable engine, which is one of the reasons I’ve been using it for so long and I always try and utilize it whenever a mobile game project comes along.  And that’s why this issue feels so out of place, especially with not being able to find any other references to it. It’s an anomaly that, to all intents and purposes, *should* work.

#18

Greetings.

I was wondering if there had been any progress on this issue? I created a shell project which demonstrated the problem and filed a bug report with support.  I know you guys probably have a huge to-do list of stuff that’s far more important than this relatively minor thing that most people wouldn’t even be using, but I would like to get it resolved so that I can finally deliver the app to my client.

Many thanks!

#19

Our engineering team has been busy as we prepare to release a new public release this week and I’m pretty sure they’ve not had time to look at this. But I need to find the bug report and do some investigation on it.  Do you have the Case ID # that would have been emailed back to you?

Rob

#20

Thank you Rob, much appreciated.

Not sure if this is the case #, but it was appended to the subject of the email reply I got: 8162523

Cheers, Niilo