I’m not sure. The code is just displaying the image it gets back from the API call.
On their homepage there are directions for getting high resolution images.
[quote=420768:@Bob Keeney]On their homepage there are directions for getting high resolution images.
Add @2x before the file extension on a URL to request an image at double scale[/quote]
Thanks, Bob. Looks like that works, although the Horizontal/VerticalResolution needs to be adjusted from 72 to 144. I’ll play around with this tomorrow and get the project updated so that it requests the right type of image based on the screen resolution.
@Paul Lefebvre - why did you chose to have a static picture in a desktop application instead of presenting the map in a html-viewer ? Providing of static pictures is a great option of the Mapbox API, but thought it was more or less meant for reports and documents.
btw: seems sample application Eddie’s Electronics (desktop) has a scope-issue with variable ‘invoiceNum’ in method ‘DeleteInvoiceItems’
Previously I had been using JavaScript that I loaded into an HTMLViewer to show a Google Map, but that was causing security issues as most platforms don’t want you loading JavaScript that hits external URLs in that way. A static map made more sense to me since it didn’t seem like the map needed to be interactive and MapBox had a free API for that. They may also have something for interactive maps, but I was concerned about the same security issues popping up and I wanted to avoid that for this demo.
Can you elaborate?
Demo EEDesktop - just loaded from the Examples-folder and hit Run.
Weird. I am definitely not seeing that error in 2018r4.
However, it looks like the “invoiceNum” parameter is already a String so the Str method is not needed there. I’m not sure why it would be causing an error for you, though.
There were some versions where str(aString) would lead to such an error. What data type is invoiceNum?
@Paul Lefebvre / @Ulrich Bogun
At least on Windows you cannot throw a string into a Str function
So, since invoiceNum is already a of type string , you just should remove the Str here and the problem is fixed.
And, weird, the documentation says the value of the Str function goes as a variant, but you can only use value types Boolean, Date or Color.
This is a great example of why I like variable type prefixing. “invoiceNum” implies that it’s a numeric value, but it’s a String! Sure it’s just a small oversight here, but with a consistent variable naming policy that includes variable type it would have been clear from the start 
It’s a good practice to get into the habit of, and may save you some head scratching in larger, non-example projects!
Exactly: sInvoiceNum would be better.
With a strongly typed language like Xojo, I think that’s unnecessary, inconvenient, and harder to read.
Just an opposing viewpoint.
DIM ThisReallyIsaStringNotaNumberInvoiceNumber As String 
Unnecessary and inconvinient like your over-spacing around parens? 
Better and more descriptive than some of the variable names we see around here 
(Style is all opinion! Mine is that type prefixing is super helpful and useful.)
[quote=420932:@Kem Tekinay]With a strongly typed language like Xojo, I think that’s unnecessary, inconvenient, and harder to read.
Just an opposing viewpoint.[/quote]
As long as you’re consistent and it makes sense to you, your clients not only now but to your future selves then you’re good. Also throw in other people that will have to fix something in your code years down the road.
But, I’d also agree that sInvoiceNum, or some variation thereof, is better because looking strictly at code (not having your mouse over it) it is impossible to tell what invoiceNum is. I like being able to tell at glance what the datatype is. And yes this means if you change it from string to integer for some reason you must change the prefix - it’s not that hard - really.
This is almost religious war material so you be you. Peace.
“Almost”?
Because the docs say Str() expects “any numeric, Boolean, Date or Color expression”. Which a string is not (necessarily). IMHO the compiler should complain here.
Hmm … it was not my intention to pollute this thread about Maps with a discussion about using prefixes and a bug in demo-code.
But, since this thread is already far off straight track, I must say I don’t like not being able to run a demo program right away without being stopped by compiling issues. Think this demo application was probably not very well tested on the Windows platform. Keep in mind that newbies wouldn’t know what to do here.
Let’s close here… summarized I am most happy with the discovery of Mapbox , which is a great free mapping solution.
Let me add one point of self-correction:
I think I was wrong saying some versions of Xojo show this error.
Could it be you are using plugins? If I remember correctly, the error does not appear with a clean installation of the IDE.
And now I am silent here too.
Yes, I have some MBS plugins loaded which fill in what Xojo doesn’t provide currently, so no chance to go without. But anyway, this Str function was needles here.