|
What I want to do is that I will compile the same application as either unicode or non-unicode without modifying the source code. I also do not want to assume the use of Windows. Maybe I have to use the typedef rather if that is better or the best way.
|
|
|
|
|
Personally I wouldn't bother with the effort of abstracting stuff to have different builds for different character widths. These days use wchar_t (either UTF-16 on Windows or UCS4 on Unixy platforms) as the internal representation and char as the external representation (as UTF-8). Anything else tends to be overcomplicated and not really worth it in my experience.
If you really have to do that though you can define your own character type and get a similar effect to using TCHAR under windows (and, as a bonus, get rid of stuff in capital letters).
Cheers,
Ash
|
|
|
|
|
Another thing: do you really want to change the file format depending on how you build the application? That will imply you won't be able to read a UNICODE built app's data file from one built without it and vice versa. Would it not be nice to have a single file format, no matter how your app is built?
|
|
|
|
|
I am using Nuance's SAPI to create a voice recognition training box, which I call with their function:
hRes = m_dgnEngine->DlgShow( dgndlgGeneralTraining, NULL, CComVariant( ), CComVariant( ) )
while I don't think showing that function is important with regards to the question, the problem I am having is the window that pops up is centered on my primary monitor, but I really want it to open on a different monitor.
I cannot simply change the primary monitor in windows and I cannot create their window any other way.
I know I can get the handle of the window, but is there a way in C, C++, or VC++ to move a window that you, technically, have no control of?
modified on Wednesday, September 8, 2010 3:29 PM
|
|
|
|
|
So basicly, you are asking if there is a way to control something you have no control whatsoever of? Sounds like a 'no' to me. 
> 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. <
|
|
|
|
|
Kinda. I'm not sure if there's something that can manipulate dialog boxes in these languages. I want to think that there would be a way to somehow get to the wndproc messages and move the box.
Or perhaps there is a simple method to do this with the handle of the window.
|
|
|
|
|
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. <
|
|
|
|
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)