|
With the handle you can use MoveWindow[^] or SetWindowPos[^], does that Show call you issue display the window and return or does it bring up a modal dialog and return only after it was dismissed? If it shows and returns you should be able to use the forementioned methods -if you have the window handle- to position it. Things might look a bit grim if the window that call shows is handler by some other-than-the-main-gui-thread.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Looks like MoveWindow shot that message off to the dialog box to resize and move it. The dialog box is still functional too, so everything is looking good. If there's any problems now, I'll post a reply, but I do think this is answered as of right now.
There's so many methods in MFC, it's hard to keep up
Thanks a ton!
|
|
|
|
|
No probs, glad to help.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
You could try something along these lines:
- try and identify the window you want to move; e.g. use EnumWindows() and GetWindowText() to find the window based on it's title text.
- then send a WM_MOVE message using SendMessage. tell the window to move, I think by calling MoveWindow()[^].
This may or may not work; it would be easy to teach a window to be unmovable, but it isn't standard practice.
|
|
|
|
|
Isn't WM_MOVE[^] used to "tell" the window procedure that the window was moved rather then actually moving the window?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I guess you're right (I'm no longer familiar with all the low-level Windows stuff); a simple MoveWindow()[^] should be sufficient!
|
|
|
|
|
|
Could you post your code? Maybe we can help you to fix it.
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]
|
|
|
|
|
I've never had to work with 8 bit per pixel images, but they are fundamentally different from 16 bpp or 24 bpp images. And 24 bpp images are easier to work with in some ways!
In a 24 bpp image (as I'm sure you know), you have a byte each for intensity of red, green, and blue components.
In an 8bpp image, each pixel's byte does not contain a value which can be directly interpretted as a colour value. Instead, the pixel contains an index to the pallette, where the pallette is effectively a 256-element array of 24 bpp colour values (I seem to remember that there is something peculiar in the palette, so maybe it is 240 element not 256 element, where 16 elements are "system colours" and have fixed values, or something like that.)
Have a look at the MSDN SAVEBMP.C example. It's painful but it will work! (But I'm really glad I only ever had to save 16bpp and 24bpp images based on SDK examples like this.)
|
|
|
|
|
Hi,
Is there a way to avoid taking screen shots of my application? I need to avoid Print Screen as well as other utilities doing the same.
Any suggestions or hints are greatly welcome.
Thank you.
- ns ami -
|
|
|
|
|
No. If it's important enough it will always end up on Wikileaks.
|
|
|
|
|
"Is there a way to avoid taking screen shots of my application"?
Don't write application that can be installed on system that have a print screen function the used payed for!
NOTE: it seem a recently recurring question: "how can disable this or that OS feature to make my application safe for these o those reason ???"
You are not the owner of your user's computer. Modifying the system behavior in not legal. (And I -an may people like me- retain also very immoral. I can seriously taking in consideration not to buy your application).
Unless you own the computers but ... in that case you better configure the system appropriately that writing application to make the entire system their only-own slave. What happen when ten different application are needed on a system each one wants it to behave differently?
2 bugs found.
> recompile ...
65534 bugs found.
modified on Wednesday, September 8, 2010 8:14 AM
|
|
|
|
|
Are you embarrassed about your UI design?
I suppose you might be able to RegisterHotKey and grab PrntScr for yourself.
But users could run some other screen capturing program. Using DirectXYZ won't help either - people take screen captures from games, after all.
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?
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Just a side-question: would placing your flatscreen on a scanner actually work i wonder? I mean, since the scanner has a bright lightsource i supose the reflection of that (on the screen) would supress the light coming from the display. If there's a way to turn the scanner's lightsource off (or to not turn in on in the first place) and do the scanning than i supose it could work...but it would probably produce some fancy interference/refresh-asynchronity artifacts.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
That's nice...
- ns ami -
|
|
|
|
|
Code-o-mat wrote: Just a side-question: would placing your flatscreen on a scanner actually work i wonder
I'm not sure myself. I'm pretty sure a CRT would not work. But an LCD/TFT? It's almost worth an experiment!
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
I wonder what my colegues here would say if i were to try that...
They'd probably say i am a few bits short of an integer...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: Just a side-question: would placing your flatscreen on a scanner actually work i wonder?
I probably lose nerd points for speaking this out loud...
you could also use a digital camera for that matter.
Btw, it works. Kind of. I tried and put my laptop screen on a scanner and the result was very stripy and hard to read, still it was possible to identify icons in the background and Google logo in Firefox. Mystery solved?
|
|
|
|
|
Yeah, i know how it sounds but still, it's not that obvious if you think about it...
Moak wrote: you could also use a digital camera for that matter.
with flash of course, don't forget the flash so your screen won't look too dark. :P
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Code-o-mat wrote: Yeah, i know how it sounds but still, it's not that obvious if you think about it...
I know what you mean, once I had the idea in my head I had to try it out.
|
|
|
|
|
And? Did you get true holographic imagery as i suspect one would if one had to try? :P
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Hehe.
What wonders me that the scanned quality is so bad, maybe has something to do with overexposing/interference from two light sources (scanner and screen).
|
|
|
|
|
If possible, try to turn the backlight off of the screen.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
Moak wrote: Btw, it works
And to think, I thought I was talking rubbish...
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
We have a saying that goes "A good priest learns until his death.", don't ask me where that came from though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|