Steve Maughan

Thanks but this seems to be C++ only.

Thanks! I thought we were due for an update soon

Are we due for an updated Delphi roadmap?

I've now updated the API to get the common data path to: result := IncludeTrailingBackslash(TPath.GetPublicPath) I thought that would fix it but unfortunately not — the application is still not seeing the virtualized folder.

Thanks! So how do I access the files? I would have assumed Windows would provide the virtual path when I call: SHGetFolderPath(0, CSIDL_COMMON_APPDATA, 0, SHGFP_TYPE_CURRENT, @path[0]) Is this not the case? Steve

I'm trying to prepare my application for the Windows Store. I'm new to APPX applications so have some basic questions — I hope someone is able and willing to help. I created the APPX file using Advanced Installer. This seemed easy. The application installs a lot of data into the common app data folder (usually in "c:\Program Data\Cozmix\AlignMix"). When I sideload the application there are no errors. However, there is also no data in "c:\Program Data\Cozmix\AlignMix". I assume it has its own virtualized version of this folder — is this correct? I then store an activation key in the same folder— which I can't see. My question is as follows: is the common app data folder the right location to store APPX application data? If not, where should it be stored? Thanks, Steve

Interesting idea!

Fascinating! I didn't think code signing certificate providers had a pecking order! Has anyone else had this experience?

Hi Fred, I gave that a try and it didn't work. I can't imagine Google penalize you for storing stuff on their storage solution. Thanks, Steve

Hi Lars, The Softpedia comment is well taken — I'll remove it now. Can I ask which version of Google Chrome you're using? Thank!

The only review I could see was the for Android APK applications. I haven't been able to find a way of submitting this issue — any clues appreciated.

Hi, Google Chrome has started to block the downloads of my application (https://www.alignmix.com). We offer a trial download so anyone can try the software and decide if it's for them. We've been doing this since 2015 with no problems. The application is business-to-business application that helps companies design their sales forces territories. It doesn't contain any malware at all. Everything is done with the user's permission. It is quite a large application at 157 Mb. When the user clicks on the download link they will see the download progress in the bottom left hand corner. Once downloaded Google Chrome informs them "AlignMix-2019-Setup.exe may be dangerous, so Chrome has blocked it" (see the screenshot). There is only one option, and that's to "Discard" — it's not a warning, it's the only option for the user. The only way around this is to delve deep into Google Chrome's setting and disable the "protection" feature and then re-download. I can't see many users taking this route — most, if not all, will simply move on and try to find another solution. The "Discard" button take you to this information page: https://support.google.com/chrome/answer/6261569?visit_id=637231503147981989-2256574895&p=ib_download_blocked&hl=en&rd=1 Which then takes you to this page, " learn how to resolve malware or unwanted software issues": https://support.google.com/webmasters/answer/3258249 When I run a "Security Issues Report" there are no security issues on the site — see screenshot. AlignMix conforms to the software guidelines. This is serious. Since 60% of the visitors to our website use Google Chrome this will have a massive impact on our business. It could jeopardize the viability of my business. Is this the start of Google's war against desktop software? Does anyone have an advise? Has anyone come across this before? All help appreciated! Steve

I posted the small project to GitHub in case it's of interest to others: https://github.com/stevemaughan/Background-Render Steve

Done! I've attached my solution for those interested. Here's a brief explanation: Whenever the color changes I create a render thread derived from TThread The render thread has an ID (GUID string) and a color (or drawing parameters) I record the last created ID When the thread has completed rendering it posts a message The main thread processes the message, checking to see if the ID is the same as the last ID. If it is then it's draw All render threads are then destroyed Works like a charm! What was tripping me up was wanting to rely on a threading library (which I'm not that familiar with). In this case it was much simpler to create my own thread. Thanks everyone — Steve Background-Render-FINISHED.zip

This seems like the most obvious way to tackle the issue. I'll report back on progress. Thanks, Steve