The UAC came out in 2006 with Windows Vista. It is now 2014, which makes it utterly ridiculous that XOJO doesn’t have the ability to set the UAC to trigger at launch in the EXE’s manifest.
VB hacks and such are not the answer. The EXE needs this when compiled.
Sheesh, even the defunct WiseScript and the free AutoIT has the ability to do this with ease. And it goes without saying that Visual Studio has this as well.
I love XOJO, but lets GET GOING on this!!!
Is there a Feedback case for this?
Yes, in general it would be nice to provide a manifest to be embedded on Windows.
(Even if that requires installation of some Visual Studio things to have command line tools to that)
There’s really nothing special involved. You just have to mark the manifest to "requireAdministrator’. WiseScript and AutoIT have it, and I can tell you there’s no funky Visual Studio plugins involved with those applications.
Seems really bizarre.
I’ll add it to feedback, but I know others have complained about it…so it’s probably already there.
Should just be a checkbox under build settings.
case 6297, I think is it.
In general it would be nice to see the IDE do some thing automatically.
Like a checkbox info.plist entries on Mac (like Retina) and some checkboxes for things you do on Windows typically with the manifest file.
OK, I’ve got a 3rd party work-a-round. I found two tools that can edit the manifest file on a XOJO app. All you have to do is change <requestedExecutionLevel
level=“asInvoker”
to
<requestedExecutionLevel
level=“requireAdministrator”
The two products are XN Resource Editor (free) and Resource Tuner ($40). Google either to find.
So yeah, over 7 years since the UAC debuted with Vista, and no built-in option to change ONE string of text in the manifest. Embarrassing.
Why can’t Xojo implement even the basic things? 64 Bit App (excuse: Compiler switch), Auto-Layout for Desktop/Web (excuse: first available with iOS support. OK, if the framework can handle it, then why do you need to delay other targets?) UAC? I can’t even fathom the excuse. Xojo, please implement what seems to be the easiest things to implement.
I also find it ridiculous that 64-bit support was first promised 2 years ago (2012 XDC/RSDC) and that is the easiest thing to implement! If Apple released iOS without some promised features and blamed the compiler, there would be a uproar. But Xojo? Not a peep. Oh, and iOS support is going to be limited for the first year.
If this is all so easy how bout you write a 64 bit compiler for us?
And the frameworks and linkers ?
[quote=59822:@Norman Palardy]If this is all so easy how bout you write a 64 bit compiler for us?
And the frameworks and linkers ?[/quote]
i’ll do it for you: alone in about a lifetime, with 2 people in 2 lifetimes.
It’s a huge project and takes a tremendous amound of time. Or you need to have MANY working on this project, with the exact same idea to end with. Wich is again pretty impossible.
I think Xojo began a bit late on this, but it’s still A LOT of work. It’s just my 2c.
[quote]OK, I’ve got a 3rd party work-a-round. I found two tools that can edit the manifest file on a XOJO app. …
The two products are XN Resource Editor (free)[/quote]
Interesting.
I just opened my app with XN Resource editor , changed this entry, hit save, and ended up with a 36K file of nothing much.
Program totally trashed.
Couple of surprising resource names in there too… 
[quote=59844:@Derk Jochems]
I think Xojo began a bit late on this, but it’s still A LOT of work. It’s just my 2c.[/quote]
We’ve actually been working on the frameworks for about 2 years
Thats a big job because we have 2 choices
#1 is actually “simpler” but it’s still a big job as there are lots of places where things like 32 bit int’s and pointers were used interchangeably which may not work when you move to 64 bit (ptrs might be 64 bit but integers may be 32 bit or various other issues)
There’s still work to do but it is under way to get the remaining bits going
[quote=60003:@shao sean]
From the other threads I’ve read, I thought 64-bit support was just a compiler flag that needed to be set? It’s taken two years to do that?
[/quote]
Well sure
We’ll flip that flag on once we finish implementing the ESP plugin 
You need the ESP plugin to know we want 64-bit compiles? All you need to do is scroll up a bit
No.
Hence why we actually started work on making frameworks & other bits 64 bit clean a few years ago (yes YEARS ago)
The frameworks build as 64 bit BUT without a 64 bit compiler for our language that doesn’t tell us much as we an exercise them yet to find bugs do regressions tests etc etc.
So the next step(s) are the new compiler & linkers so we can create 32 & 64 bit applications with those 64 bit frameworks.
There really is a plan
It just takes time for all of it to come together in the right order - esp when some of the bits we don’t control
Bits 33 to 63 ?
Things like lldb and native linkers
The compilers are not an issue but without debuggers & linkers it’s not useful