No subject

[Andrew Kluthe]

I'm already doing this, I've already explained why LC's built in encryption
wont work for me. Nor do I need it to work. Nor do I need further advice on
the rest of my implementation that I didn't come seeking advice on. I've
said several times that I came looking for information on a specific
message for a specific. I got my answer, I've tried to be polite and sate
your curiosity in what I am trying to accomplish. I made a grave mistake.

I get that there might be threading issues with the messages in this
series, but lawdy lawdy the signal to noise ratio is insane around here
these days.

On Fri, Feb 6, 2015 at 7:07 PM, Bob Sneidar <bobsneidar at iotecdigital.com>
wrote:

> IC so then the suggestion of encrypting the data before writing it to the
> HD is probably a good idea. It’s a simple thing to do:
>
> encrypt theData using aes128 with theSeedValue
> put it into theEncData
> get empty -- for safe measure
>
> and the seed can be anything you want it to be.
>
> Bob S
>
>
> On Feb 6, 2015, at 17:00 , Andrew Kluthe <andrew at ctech.me<mailto:
> andrew at ctech.me>> wrote:
>
> Yeah, it's pretty similar. I still kind of run the risk of not being able
> to tell it when to delete the file as this is going to be a long running
> application (one that stays open most of the day, or days? it's a parts
> lookup and interchange program) on the users system and I wouldn't be able
> to set the AT command at end process the same as me being unable to call
> any kind of lc script when it does.
>
> It's in an obscure but vulnerable state when its open anyway so this one
> little thing isn't a huge issue. I was just looking to see if there was any
> kind of message at all that was sent to a stack on ending a process like
> that on windows.
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
Regards,

Andrew Kluthe
andrew at ctech.me