‘even though I went to your website, tried the demo, bought the software with my Paypal account, downloaded it, installed it 2 months ago and registered it from my own IP address with my own email address -
this was a fraudulent sale’.
Im curious: in what way did this inconvenience the customer?
And could you look in the trash folder for files that match your naming pattern, and delete them on startup?
Warning: Tomorrow customers will ask a module to build a story after giving the software a bunch of words (less than 10) and selecting a domain (say Police Story, Romance, Science Fiction and so on ) ?
When will customers start to ask for an ESP module ?
Sometimes I am at short (the reading let me with no idea, nothing to say, that is why I do not chime in on Jul 6.)
There is. Instead of just creating, using temporary folderitems and letting them go out of scope, create a new class which contains a temporary folderitem which will automatically delete the file(s) for you when the class’ destructor fires.
[quote=341912:@Emile Schwarz]Recovered Items ?
If so, I would add code in Cancel Quit (or Quit) Event that scan that folder and if it find a folder called Recovered Items, open it, clears it and delete it (at last).
Isnt it possible to do that ?[/quote]
I believe that leftover items in the Temp folder are moved to the Trash/Recovered Items folder upon reboot, so that your Xojo app would never have a chance to do that, unless your Xojo app runs automatically upon login (which mine does not).
I don’t know if it’s a mutex causing this, but Feedback is leaving a temporary file behind. I just opened Feedback 2017r1.2, then closed it and logged out. Upon logging back in my .Trash directory contained a 0 byte file named “Xojo Feedback” in a dir named “Recovered files”.
Here’s info on that file:
$ ls -l@
-rw-r--r--@ 1 user staff 0 Jul 25 06:55 Xojo Feedback
I just did a quick test. Entering a Mutex does indeed create a file in Temporary, and Leaving it deletes it. Quitting without explicitly calling Leave deletes it too, but perhaps if it’s located somewhere where its Destructor doesn’t necessarily fire, it won’t.
If it’s the Mutex at all, perhaps explicitly call Leave in the App Destructor? Or do what I do, create a wrapper class that holds the Mutex (or a Semaphore or CriticalSection) that calls Leave in it’s Destructor. I use it like this:
dim m as new Mutex( "MyApp" )
dim holder as CSHolder = CSHolder.TryEnter( m )
if holder is nil then
// Couldn't get it
// Some code
holder.Leave // Not strictly necessary as its Destructor will Leave it
If your code exits early from, say, an exception or early return, the Mutex should still be unset.