Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: .NET WPF Forms

Disclaimer!

 
This Question is asked just for fun.
 
Few CodeProject members expressed their interest in my idea of the competition
"Most Elegant and Comprehensive Solution of a Completely Useless Task".
 
I've chosen the title "Completely Useless Challenge". I promised to come up with the idea of some interesting problems. Here is my first one.
 
I would like anyone to avoid votes based on practical considerations (and perhaps any down-voting). The purpose of the Challenge is to show off some programming muscles and have fun. It the same time, I would not be surprised that the Answers will show useful techniques in terms of robustness, programming styles, readability, elegance and supportability of code. This and only this should be useful, not the application of the technique.
 
The answer can be published as CodeProject articles and referenced in the Answer. Just ideas or simple codes can be posted as Answers.
 

Mouse-hating UI library

Here is the problem. We need a universal UI library aimed to punish users trying to control UI with the mouse. Indeed, who needs mouse? Everyone knows that mouse operations are much slower than keyboard operations (when the UI is really keyboard-friendly). In contrast, using only keyboard boost effectiveness, develop user's memory and improve the user's self-esteem and SOI (Sense of Own Importance). To promote good user's behavior and skills, existing UI applications need an advanced feature which punishes the user for using mouse. Smile | :)
 
The primary target for the library should be .NET System.Windows.Forms and WPF. Other libraries are welcome. The library should be absolutely universal. For this purpose, it is required that a new behavior is applied in just one call (for example, with the parameter of Application or main Form). It is not required to work with any application: the library can be added to the target project and its main method is called (presumably, from application entry point).
 

Expected Behavior

Every time the user clicks any location in the application's form, window, control or framework UI element, she or he should be punished by making a hole in the window at the location of click. It should be a true hole: clicking in the hole should trigger events in the window of the application underneath, not the application using the library. The application run-time should calculate the score of user's mistake: from time to time the size of the new holes grows depending on the score (number of unwanted uses of the mouse). See for additional challenging requirements below. It's nice to accompany the punishment acts with different sounds, depending on the score and perhaps other factors (click in control of window, depending on the level of clicked controls, etc.). The clicks on a control should be completely disabled, so no "useful" effect of mouse click is allowed.
 

Challenge #1:

The behavior described above should be applied for clicks in non-client areas as well.
 

Challenge #2:

The behavior described above should be limited to "useful" mouse clicks only, that is, if without the mouse-hating feature nothing happens to the UI, such click is not punished. I think this requirement is hard to implement.
 

Challenge #3:

The holes can be decorated. The hole can get irregular shape with burned edges of irregular shapes. The burned edge should be a part of a window/form, but the hole itself should not.
 

Technical Notes:

The implementation of holes with System.Windows.Forms is easy: it is defined by the Region property. For WPF, it can be done using combination of WindowStyle="None" AllowsTransparency="True" and setting of the property Clip to some custom Geometry. Unfortunately, this method does not allow showing non-client area of the window.
 

—SA
Posted 6-Mar-11 12:42pm
Edited 5-Jun-14 19:23pm
v18
Comments
Espen Harlinn at 13-Mar-11 16:23pm
   
Sounds like a bit of fun :)
Angela 10293848 at 4-Jan-14 7:27am
   
oh my computer!!!!!!!!!!!:))))))))))))))
SAKryukov at 13-Mar-11 16:58pm
   
Thank you.
I have 2-3 other ideas, but want to see what happens to this one.
I wish I could invent something which is easier.
--SA
Member 8043849 at 3-Jul-11 20:07pm
   
its a long term and deep project ..... but possible.
now college time so in next vaccation......
Member 8043849 at 3-Jul-11 20:07pm
   
its a long term and deep project ..... but possible.
now college time so in next vaccation......
SAKryukov at 5-Jul-11 0:05am
   
It depends how much of the task you want to take. Basic feature is relatively easy to implement in well-predictable time frame, but each of the challenges #1 to #3 are difficult, I think; hard to tell how much time it may takes, all need some research.
 
Cheers,
--SA
ashika menon at 3-Aug-11 7:27am
   
:)
SAKryukov at 17-Nov-11 11:38am
   
:-)
Rakshith Kumar at 30-Oct-13 5:47am
   
Well tough requirement. SHould give A TRY atleast :). Possible
Sergey Alexandrovich Kryukov at 30-Oct-13 9:17am
   
The solution is of course possible, it just needs considerable effort... :-)
—SA
NeptuneHACK! at 19-Jan-12 4:45am
   
(SAKryukov) a God Damn Genius!!!
LIKE!
SAKryukov at 19-Jan-12 4:50am
   
You are a shameless flatterer, but thank you.
--SA
BillWoodruff at 20-Jan-12 3:27am
   
Voted up for the sheer quality of the fantasy ! :) But, sorry, no time to fish for blind-fish in deep caves.
 
Of more interest, to me, would be the challenge of an efficient macro-recorder strategy that would allow custom-key mapping for short-cuts to an application's most frequently invoked functionality (or sequence of actions). A problem which I believe implies the ability to turn on, or off, the monitoring of all input events (mouse, mouse-buttons, or keyboard) of any type.
 
best, Bill
SAKryukov at 20-Jan-12 4:11am
   
Believe or not, but the problem you are described is pretty easy, but system-wide recording cannot be implemented in .NET (but playing of macro can be, with P/Invoke). To me, this is not so interesting.
Thank you for voting.
--SA
BillWoodruff at 20-Jan-12 6:01am
   
Once again, thanks, SAK, you reminded me that I have never looked at the problem of creating a UserForm or Control with a custom region in place which then has "subtracted" from its current total custom region, an inner region ... completely within the bounds of the initial region.
 
Back in the days, so long ago, when I was at the guru-level in PostScript this would have been so simple: just combine two paths built using different "winding-order" rules. But, that's ancient history :)
 
And, yes, I agree the problem of creating a macro-recorder observing only events within the current application is very do-able, and I have read, before, that system-wide recording is impractical in .NET (even though we can, as several CP articles show us how to do, install global mouse and key hook-handlers).
SAKryukov at 20-Jan-12 11:46am
   
It may be not impractical but just impossible. I tried it in pure native code. On my site, I have my old virtual desktop for downloads. All moves of the windows on a read desktop are mapped on a miniature chart showing the desktop immediately on any changes on a real desktop. The only way to do it without wasting any CPU time on periodic polling is Windows Hooks, with a global hook installed in a separate DLL. Now, I found in Microsoft documentation, that this DLL can only be a native DLL, not a .NET assembly (with P/Invoke), I don't really know why, just a fact. If so, the application can be all in .NET except this native DLL. Same thing about system-global recording: in needs just one executable module in the form of native DLL installing the hook and performing the primary processing of input events system-wide.
--SA
krumia at 8-Jun-12 7:15am
   
<blockquote class="FQ"><div class="FQA">Quote:</div>I have 2-3 other ideas, but want to see what happens to this one.</blockquote>
So, after some time, what were those ideas :D
Krunal Rohit at 12-Dec-12 4:46am
   
I didn't get the basic idea, could you please explain me a little bit more about it ??
Sergey Alexandrovich Kryukov at 12-Dec-12 11:29am
   
Thank you for your comment. As I think I put a lot of detail already, to answer your question, I would need to know -- in what part you need more explanation? what are the concerns?
 
First and foremost, this is a kind of programming joke; fun stuff which can be useful for sharpening programming skills though. :-)
--SA
Krunal Rohit at 12-Dec-12 21:47pm
   
Ya that's why I asked you.. I'm not getting Expected Behavior part.
Sergey Alexandrovich Kryukov at 12-Dec-12 22:45pm
   
Well, how else can I explain it. You click on application, and instead of normal mouse behavior, the application gets a whole in the window where you clicked the mouse. A real hole...
--SA
Krunal Rohit at 12-Dec-12 22:51pm
   
Ummm.. bit difficult but I'll give it a try ASAP... Its exam time now.. :)
Sergey Alexandrovich Kryukov at 13-Dec-12 0:40am
   
Appreciate your virtue :-)
—SA
Krunal Rohit at 14-Dec-12 6:31am
   
Thanks, Have you tried out anything on this ?
Sergey Alexandrovich Kryukov at 14-Dec-12 13:29pm
   
Yes, a non-rectangular System.Windows.Form and WPF Window (with a hole or anything). Basically, I know all parts needed. Challenge #1 and #2 would make it more difficult.
—SA
Krunal Rohit at 15-Dec-12 1:59am
   
I got one point that, we can make that much of point's color transparent...
Sergey Alexandrovich Kryukov at 15-Dec-12 2:19am
   
No, this is the whole point! You did not get it. It would be a fake solution. In a real solution, the hole is real.
Do you understand what does it mean? Read again.
—SA
Krunal Rohit at 15-Dec-12 2:22am
   
So what would be other way ?
Sergey Alexandrovich Kryukov at 15-Dec-12 2:35am
   
Is that the question on how to do it, or how it should work? Everything is described above.
—SA
Krunal Rohit at 15-Dec-12 2:38am
   
I'm bit confused with hole. Hole like what ?
Sergey Alexandrovich Kryukov at 15-Dec-12 2:41am
   
You click in it, and it does not behave like a part of a window. I already explained.
—SA
Krunal Rohit at 15-Dec-12 2:44am
   
Need some time to understand..
Krunal Rohit at 18-Dec-12 21:32pm
   
Okay, now I got understood your scenario.. You want to make a complete hole on windows, like on click, that much of area of windows could be eliminated from it.. Is it so ?
Sergey Alexandrovich Kryukov at 19-Dec-12 4:01am
   
Yes. Eliminated. Excuse me, you apparently fail to read properly: in the last section, "Technical Notes", I even explained how to do it. It would be easier to try and see how it behaves.
—SA
Krunal Rohit at 19-Dec-12 8:22am
   
Ya concept is clear to me... I just don't have to describe as you have... I'll give it a try..:)
Sergey Alexandrovich Kryukov at 19-Dec-12 18:03pm
   
Great. Good luck.
—SA
Krunal Rohit at 6-Jan-13 10:16am
   
I'm able to make a hole using Rectangle and Region properties of Forms... I've tried a lot but it works only once... and ya it makes hole in Rectangle shape.. Ummmm, we can't say it's a hole.. Could you guide me on this ?
Sergey Alexandrovich Kryukov at 6-Jan-13 12:58pm
   
If the whole you make is something that "we can't say it's a hole", that's not it. Guiding you? Well, I could, but don't forget: I'm the inquirer here, not you. :-)
—SA
ProgramFOX at 9-Jan-13 12:30pm
   
Nice challenge! I'm trying this! But Challenge #2 is very hard, as you said.
Sergey Alexandrovich Kryukov at 9-Jan-13 13:45pm
   
It is, but I'm sure it's solvable.
Thank you,
—SA
Michael Haephrati at 7-Mar-13 9:09am
   
Great Idea! LOL
Sergey Alexandrovich Kryukov at 7-Mar-13 9:49am
   
Thank you, Michael.
Just a joke, mostly... :-)
—SA
Syed Asif Iqbal at 6-Jun-14 0:33am
   
Indeed its fun, Good idea btw
Sergey Alexandrovich Kryukov at 6-Jun-14 1:52am
   
Thank you very much, Syed Asif.
—SA
Prasad Avunoori at 6-Jun-14 3:21am
   
Solution could become a windows game rather than an application. :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



Advertise | Privacy | Mobile
Web04 | 2.8.1411022.1 | Last Updated 6 Jun 2014
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100