Most of the group will remember Robert Green.
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Choices-in-Desktop-Dev...
An easy quick session that explains various opportunities available today. The statement Apps are Apps is so true.
It used to be that you could get a much richer user experience in a desktop app compared to a web app for many head-down data entry kinds of apps. Is that still true to the most extent?
On 3/29/2021 10:32 AM, Stephen Russell wrote:
Most of the group will remember Robert Green.
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Choices-in-Desktop-Dev...
An easy quick session that explains various opportunities available today. The statement Apps are Apps is so true.
I would say that those days are just about done. With webAssembly and interfaces like d3.js, three.js and gaming engines such as babylonjs it is hard for me to justify writing a traditional interface.
One of the key points though for data based applications is the fluid use of linking between topics. Anything on the screen can cause a navigation event. So if I have a map, it is trivial to put a picture of a truck on the map and have its details appear with a click. Users can drill through reports if they are in HTML.
Anyway you get the idea ... I'm on board.
On Tue, Mar 30, 2021 at 1:50 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
It used to be that you could get a much richer user experience in a desktop app compared to a web app for many head-down data entry kinds of apps. Is that still true to the most extent?
On 3/29/2021 10:32 AM, Stephen Russell wrote:
Most of the group will remember Robert Green.
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Choices-in-Desktop-Dev...
An easy quick session that explains various opportunities available
today.
The statement Apps are Apps is so true.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Richer is word that can be used in two different ways. The pure speed of input of a document is negligible between the two environments.
Identification of data that is pertinent to the overall transaction, that being can we make the customer buy more. Amazon nails that with images of items that you have looked at before but not purchased. Can a desktop do that? Opening up multiple tabs to present more data to the user. Order history of customer or payments of customer and aging?
After working in the web space as well as a few older desktop apps, the desktop has been a crap fest in functionality or the graphics of buttons is so outdated, compared to what is crisp and clean on the web.
On Mon, Mar 29, 2021 at 9:49 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> wrote:
It used to be that you could get a much richer user experience in a desktop app compared to a web app for many head-down data entry kinds of apps. Is that still true to the most extent?
On 3/29/2021 10:32 AM, Stephen Russell wrote:
Most of the group will remember Robert Green.
https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Choices-in-Desktop-Dev...
An easy quick session that explains various opportunities available
today.
The statement Apps are Apps is so true.
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
It used to be that you could get a much richer user experience in a desktop app compared to a web app for many head-down data entry kinds of apps. Is that still true to the most extent?
Purely in terms of UI it's less and less true all the time - however the work involved to approach that richness of UI and deploy it safely and securely on the web is still orders of magnitude beyond doing the same on desktop. Plus you have tradeoffs around access to local filesystems, printers and so on.
But look at something like https://www.photopea.com/ for example. That to me is a good example.
I built an app that allows access to local devices and data while still being a browser, if anyone needs help in that area.
On Wed, 31 Mar. 2021, 9:57 pm Alan Bourke, alanpbourke@fastmail.fm wrote:
It used to be that you could get a much richer user experience in a desktop app compared to a web app for many head-down data entry kinds of apps. Is that still true to the most extent?
Purely in terms of UI it's less and less true all the time - however the work involved to approach that richness of UI and deploy it safely and securely on the web is still orders of magnitude beyond doing the same on desktop. Plus you have tradeoffs around access to local filesystems, printers and so on.
But look at something like https://www.photopea.com/ for example. That to me is a good example.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On Mar 31, 2021, at 14:11, Paul Hemans paul_hemans@laberg.com.au wrote:
I built an app that allows access to local devices and data while still being a browser, if anyone needs help in that area.
I built a desktop app that communicates with a server via HTTP, allowing the app to update itself, with all the logic on the server, so that the app was a lightweight client, like a browser.
Back in 2010.
https://pyvideo.org/pycon-us-2010/creating-rich-client-applications-using-da...
-- Ed Leafe
Ed,
https://pyvideo.org/pycon-us-2010/creating-rich-client-applications-using-da...
Is there a higher-res version of that presentation?
Malcolm
On Apr 2, 2021, at 09:35, Malcolm Greene profox@bdurham.com wrote:
https://pyvideo.org/pycon-us-2010/creating-rich-client-applications-using-da...
Is there a higher-res version of that presentation?
Unfortunately, that was pretty much state-of-the-art with conference recording back in those days.
-- Ed Leafe
On 4/2/2021 10:26 AM, Ed Leafe wrote:
On Mar 31, 2021, at 14:11, Paul Hemans paul_hemans@laberg.com.au wrote:
I built an app that allows access to local devices and data while still being a browser, if anyone needs help in that area.
I built a desktop app that communicates with a server via HTTP, allowing the app to update itself, with all the logic on the server, so that the app was a lightweight client, like a browser.
Back in 2010.
https://pyvideo.org/pycon-us-2010/creating-rich-client-applications-using-da...
The last Loader utility I did (for FabNet years ago) looks at a MySQL database on the internet to see if there are any updated versions and if so, asks the user if they want to upgrade. That was many years ago as well. Works very seamlessly to download and run the new installer and immediately exit the current app to allow it without issue.
Granted, it's a short drive, but....
This is making me nuts. I've paraphrased and simplified the problem to the gist of it:
My program does COPY FILE (cInputFile) to (cOutputFile). This works great. EXCEPT if the output file is on my desktop, then I get the message: "Cannot create file c:\users\me\desktop\file.ext."
It doesn't matter that I'm an Admin user, and it doesn't matter if I also right-click and run the program as admin.
HOWEVER, if I'm in VFP and compile it with the "run after compile" option, it will compile, run, and perfectly happily copy to the desktop with no error.
Here are the rights I have on the Desktop: (You can tell I kept trying different things) The following users are on security, and each has full rights: everyone System my login machine\users machine\administrators I also have the owner as my login in Advance/change owner
Thankfully, the program works fine on my clients computer, but this is making me nuts. I'd appreciate a gentle tap with a clue-by-four. Thank you!
On Tue, Mar 30, 2021 at 10:08 AM Vince Teachout vinny@caracal.net wrote:
Granted, it's a short drive, but....
I know the feeling. I can walk from here ;)
This is making me nuts. I've paraphrased and simplified the problem to the gist of it:
My program does COPY FILE (cInputFile) to (cOutputFile). This works great. EXCEPT if the output file is on my desktop, then I get the message: "Cannot create file c:\users\me\desktop\file.ext."
It doesn't matter that I'm an Admin user, and it doesn't matter if I also right-click and run the program as admin.
Yeah, that's nuts-making.
Did you perhaps move your Desktop shortcut to another drive? I had a client issue where their personal folders were mapping to network shares and... weird things happened.
I did:
StrToFile("This is a test. This is only a test.","testfile.txt") cInFile = fullpath("testfile.txt") cOutFile = "C:\Users\tedro\Desktop\testfile.txt") COPY FILE (cInFile) TO (cOutFile)
and it worked.
Note my username is truncated (8.3!) in the Desktop path. Perhaps that's what you're running into? (In File explorer, right-click on Desktop, Properties for the creative renaming)
"A mind is a terrible thing to lose." -- Dan Quayle
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
Nope, none of the below apply. Shorcut is the default, and the behavior is the same if I navigate the path from c to users to vinny to desktop.
vinny is well under 8.3. My full path for the TO is a variable (same as yours, actually) with the value: "C:\USERS\VINNY\DESKTOP\MYTEST.PDF "
On 03/30/21 10:32 AM, Ted Roche wrote: Yeah, that's nuts-making.
Did you perhaps move your Desktop shortcut to another drive? I had a client issue where their personal folders were mapping to network shares and... weird things happened.
I did:
StrToFile("This is a test. This is only a test.","testfile.txt") cInFile = fullpath("testfile.txt") cOutFile = "C:\Users\tedro\Desktop\testfile.txt") COPY FILE (cInFile) TO (cOutFile)
and it worked.
Note my username is truncated (8.3!) in the Desktop path. Perhaps that's what you're running into? (In File explorer, right-click on Desktop, Properties for the creative renaming)
"A mind is a terrible thing to lose." -- Dan Quayle
Is the EXE somehow running in a sandbox, or compatibility mode?
Tracy
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Vince Teachout Sent: Tuesday, March 30, 2021 12:43 PM To: profoxtech@leafe.com Subject: Re: Bizarre Desktop write problem driving me mad
Nope, none of the below apply. Shorcut is the default, and the behavior is the same if I navigate the path from c to users to vinny to desktop.
vinny is well under 8.3. My full path for the TO is a variable (same as yours, actually) with the value: "C:\USERS\VINNY\DESKTOP\MYTEST.PDF "
On 03/30/21 10:32 AM, Ted Roche wrote: Yeah, that's nuts-making.
Did you perhaps move your Desktop shortcut to another drive? I had a client issue where their personal folders were mapping to network shares and... weird things happened.
I did:
StrToFile("This is a test. This is only a test.","testfile.txt") cInFile = fullpath("testfile.txt") cOutFile = "C:\Users\tedro\Desktop\testfile.txt") COPY FILE (cInFile) TO (cOutFile)
and it worked.
Note my username is truncated (8.3!) in the Desktop path. Perhaps that's what you're running into? (In File explorer, right-click on Desktop, Properties for the creative renaming)
"A mind is a terrible thing to lose." -- Dan Quayle
Maybe try snagging Doug Hennig's specialfolders.prg from here:
https://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.ht...
Then see what specialfolders("desktop") returns in case Windows is up to some sort of shenanigans.
Thanks, Alan. I checked it out, but that isn't the problem. :-(
On 03/31/21 7:03 AM, Alan Bourke wrote:
Maybe try snagging Doug Hennig's specialfolders.prg from here:
https://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.ht...
Then see what specialfolders("desktop") returns in case Windows is up to some sort of shenanigans.
A few months back I asked for help trying to figure out why my program would not let me save to my desktop (Original post below). I got a lot of suggestions, and tried a lot of things, but ultimately was unable to figure it out.
A while ago, I did another Google out of boredom, and saw a suggestion I didn't see before. I really didn't think it would work, but figured I had nothing to lose.
I turned off my (Avast) anti-virus, and was able to write to the desktop. I added an exception for the folder the program lives in, and it's worked fine since. :-|
Turns out Avast (and I guess AVG, since that's what the OP had) added a "security feature" sometime last year without widely announcing it. Since it affects some programs, and not others, it took a while to spot it, and there was no clue as to what was causing it.
Problem solved.
------------------------------------- ORIGINAL POST --------------------------- Granted, it's a short drive, but....
This is making me nuts. I've paraphrased and simplified the problem to the gist of it:
My program does COPY FILE (cInputFile) to (cOutputFile). This works great. EXCEPT if the output file is on my desktop, then I get the message: "Cannot create file c:\users\me\desktop\file.ext."
It doesn't matter that I'm an Admin user, and it doesn't matter if I also right-click and run the program as admin.
HOWEVER, if I'm in VFP and compile it with the "run after compile" option, it will compile, run, and perfectly happily copy to the desktop with no error.
Here are the rights I have on the Desktop: (You can tell I kept trying different things) The following users are on security, and each has full rights: everyone System my login machine\users machine\administrators I also have the owner as my login in Advance/change owner
Thankfully, the program works fine on my clients computer, but this is making me nuts. I'd appreciate a gentle tap with a clue-by-four. Thank you!
On that note, here's a reminder that if the product is free, then your data is the product:
https://www.wizcase.com/antivirus/avg/
(TL;DR: They were selling your browsing data)
Eric
On Wed, Jun 16, 2021 at 2:15 PM Vince Teachout vinny@caracal.net wrote:
A few months back I asked for help trying to figure out why my program would not let me save to my desktop (Original post below). I got a lot of suggestions, and tried a lot of things, but ultimately was unable to figure it out.
A while ago, I did another Google out of boredom, and saw a suggestion I didn't see before. I really didn't think it would work, but figured I had nothing to lose.
I turned off my (Avast) anti-virus, and was able to write to the desktop. I added an exception for the folder the program lives in, and it's worked fine since. :-|
Turns out Avast (and I guess AVG, since that's what the OP had) added a "security feature" sometime last year without widely announcing it. Since it affects some programs, and not others, it took a while to spot it, and there was no clue as to what was causing it.
Problem solved.
------------------------------------- ORIGINAL POST
Granted, it's a short drive, but....
This is making me nuts. I've paraphrased and simplified the problem to the gist of it:
My program does COPY FILE (cInputFile) to (cOutputFile). This works great. EXCEPT if the output file is on my desktop, then I get the message: "Cannot create file c:\users\me\desktop\file.ext."
It doesn't matter that I'm an Admin user, and it doesn't matter if I also right-click and run the program as admin.
HOWEVER, if I'm in VFP and compile it with the "run after compile" option, it will compile, run, and perfectly happily copy to the desktop with no error.
Here are the rights I have on the Desktop: (You can tell I kept trying different things) The following users are on security, and each has full rights: everyone System my login machine\users machine\administrators I also have the owner as my login in Advance/change owner
Thankfully, the program works fine on my clients computer, but this is making me nuts. I'd appreciate a gentle tap with a clue-by-four. Thank you!
-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Yeah, I just found out about this today, in the same google search. "It's since been fixed." :-(
I don't think it was just the free version, though.
On 06/16/21 4:34 PM, Eric Selje wrote:
On that note, here's a reminder that if the product is free, then your data is the product:
https://www.wizcase.com/antivirus/avg/
(TL;DR: They were selling your browsing data)
-
Alan Bourke -
Ed Leafe -
Eric Selje -
Malcolm Greene -
MB Software Solutions, LLC -
Paul Hemans -
Stephen Russell -
Ted Roche -
Tracy Pearson -
Vince Teachout