|
Well, there is one way of testing it, Why don't you try it. I suspect it won't work.
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: Are you embarrassed about your UI design?
You're The Best!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: You're The Best!
Just a little out of practise!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: Are you embarrassed about your UI design?
Never! But if the application is a viewer for a confidential document? And if the vendor never interested in redistribution of that document without his approval?
Iain Clarke, Warrior Programmer wrote: I suppose you might be able to RegisterHotKey and grab PrntScr for yourself.
Thank you. I have to check that and similar things to avoid Print Screen.
Iain Clarke, Warrior Programmer wrote: But users could run some other screen capturing program. Using DirectXYZ won't help either - people take screen captures from games, after all.
Yes. But trying to avoid such things to the maximum possible extent.
Iain Clarke, Warrior Programmer wrote: You could look to replace the shell, so people can't run other applications.
But will your software also come with an armed guard to stop people from taking photos of the screen? Placing their flat screen on a scanner?
- ns ami -
|
|
|
|
|
Nishad S wrote: But if the application is a viewer for a confidential document?
That was my guess, really. My suggestion about the UI was very tongue in cheek.
But the points given to you are very good ones.
a) It's not your computer - but that might not be true, if the environment is provided for this purpose. Think train ticket purchasing kiosks.
b) If a person can see it, they can use a camera, pen and paper, or even just their own brain cells to remember. If you can trust a user not take a photo, you can trust them not to use Print Screen. If the computer is under your control (Let's say you work for the CIA in IT), then it doesn't matter if they print screen - they have no usable USB slots to export the data!
This strikes me as a daft requirement by someone who has not given it a lot of thought.
Now, which Clancy novel was it, where every time a document was shown to someone, it had a deliberate error, so they'd know who the leak was...?
I think the only way you can stop people is to make it a firable offence to steal, and to not let unauthorised people play!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: That was my guess, really.
Great!
Your points are really valuable. I too believe that 100% foolproof software cannot be created. But I am trying to increase the difficulty to take unauthorized copies so that its frequency will get decreased.
Thank you for your suggestions!
- ns ami -
|
|
|
|
|
"But I am trying to increase the difficulty to take unauthorized copies so that its frequency will get decreased"
Yes but ... doing it illegally (or with illegal methods) is unauthorized as well.
Who are you to disable my system's features if I didn't authorize you to do so?
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Emilio Garavaglia wrote: Who are you to disable my system's features if I didn't authorize you to do so?
I am not disabling any system feature than making my application react differently... for example, when pressing Print Screen key, my application will be painted as black. That's all! 
And if I give the user full permission to take copies as he/she desires, then I have to raise the price of the product that much higher in order to meet development expenses and all. That cannot be bearable for the user. And I am not creating an open source application. So I have to deliver the product with a minimum price tag, and with enough profit. If the user makes copies and spread it easily, then my product will end in loss of money. Especially if the product is for a specific kind of people (say, technical students).
- ns ami -
|
|
|
|
|
"I am not disabling any system feature than making my application react differently"
Don't play with words: the print-screen is not a functionality that belongs to your application. Things don't become "legal" if you call them differently.
"And if I give the user full permission to take copies as he/she desires..."
Respect to what the European law says, the user HAS THE FULL LEGAL RIGHT to make all the copies he wants for his own personal use.
Trying to avoid this is illegal.
At least in the EEC.
If you want to limit the use of your application make your application binded to something that cannot be easily changed (HW dongle, registration keys, etc. etc.) but limiting the user rights about his own use of his own tools is an abuse.
Your rights about how your software is use ends where the right about how the user use his system begins.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Iain, just for completeness, your point a) is correct, but a "bad design" may be hidden.
If that's the case, it is the OS of the kiosk that should be configured not to have non-required features, not each specific application that may be developed for it (even a ticket kiosk may have many, if selling tickets for different companies) to take care about. Otherwise we are ... compensating a bad security manager with "bad" apps. Although "-*- == +" we are left with an unsafe system (in case it will run another app) and an unfair app (if running upon another system).
Unless the kiosk doesn't have an OS at all and the OS IS THE APP. But it seems not the case here.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Iain Clarke, Warrior Programmer wrote: Now, which Clancy novel was it, where every time a document was shown to someone, it had a deliberate error, so they'd know who the leak was...?
Patriot Games. The scheme was called the Canary Trap
Judy
Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein
|
|
|
|
|
The easiest thing to do is to add a small bright banner at the top of the viewer application stating that the document has been watermarked to identify leaks, w/o actually doing anything to the document. That could be intimidating enough.
|
|
|
|
|
Just one curiosity:
why is your "vendor" giving "confidential document" to people he doesn't trust?
Why should the "customer" trust you "vendor"'s products?
If the the bug is in the problem, every answer is "bad".
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Emilio Garavaglia wrote: why is your "vendor" giving "confidential document" to people he doesn't trust?
Why should the "customer" trust you "vendor"'s products?
Why was original poster looking for a possible technical solution? Because opportunity makes the thief and by limiting the quick-n-easy access you already prevent the majority of people from doing something stupid. It's why we have crappy locks on our doors, it does not keep out trained intruders/thiefs/ninjas, but still better than having them unlocked, just a little lock does a great job. Unfortunately, there is no simple technical solution to prevent data theft or screen capturing.
/M
|
|
|
|
|
Locks are only meant to keep the honest ones out.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Nobody is going to prohibit to put YOUR lock on YOUR door.
But if you want to put YOUR locks on MY door ... at least you should agree.
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
I could take a picture of the screen ... so ... do the math.
Watched code never compiles.
|
|
|
|
|
Hi all,
I have an MFC program that (amongst others) stores some files with different types (like .msg, .doc, .eml etc) When the user selects one such files, I would like to start the relevant software to open that file much like what happens when I doubleclick on a file from the explorer.
How do I do such a thing? (one: how do I find-out which program to start based on the file's extension and two: what is the easiest way to start that program?)
Thanks in advance
William
|
|
|
|
|
|
Thanks a lot. This indeed solved my issue.
Regards,
William
|
|
|
|
|
ShellExecuteEx() would automatically open the associated program based on the file type.
|
|
|
|
|
I know you mean "execute" in a computing context, ie "run".
But I had a different picture when I saw your subject heading.
exe -> *Bang!*
txt -> *chop!*
doc -> *defenestrate!*
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Although there are definately certain files that I would gladly *kill*, *exterminate*, etc You are right in assuming that my question was intended to be boringly technical.
|
|
|
|
|
I'm coding a plotting app using coordinates data saved in a .txt file.
So I need access files in CDialog::OnPaint().
But it seems not to work coz I find the file pointer doesn't move though CFile::Seek() and
CFile::Read() are used.
Or could a while loop be in CDialog::OnPaint()?
modified on Tuesday, September 7, 2010 10:46 PM
|
|
|
|
|
Krauze wrote: So I need access files in CDialog::OnPaint().
I don't think so. OnPaint() may be called hundreds of times, when your window gets resized, maximized, restored, covered and uncovered by some other window, etc. So you should read the file once, beforehand, outside OnPaint(); store all the information in an appropriate data structure, and use that inside OnPaint().
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
