|
|
Yup, on the screen.
-Masta G-
|
|
|
|
|
Use ::LoadImage ( or GDI+ ) then in WM_PAINT, BitBlt them to the screen.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Tomasz Sowinski,Thank you for your reply.
I write the code according to you:
...
#define _WIN32_WINNT 0x0500
#include "winuser.h"
...
but it report the same error "undeclared identifier".
is there other reason?
Thanks again!
Hi
|
|
|
|
|
You will probably need the latest SDK header files. If you do now want to download the Win32 SDK, you can simply include this definition in order to define the function:
UINT WINAPI SendInput(
UINT nInputs,
LPINPUT pInputs,
int cbSize
);
If you include this declaration, and you are not using any other functions that use the version 0x500 headers, then you can set WINVER back to 0x400.
Just incase you didnt know this, by using this function your program will not run on windows 95.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
I remember reading somewhere (can't find it now  ) that when you call WaitForSingleObject on an handle the thread already owns (a MUTEX for instance), the function returns with WAIT_OBJECT_0.
If this is true, do I have to call ReleaseMutex the same amount of times, or is once enough to give up ownership?
Also, is there a way to know if we own a given resource (HANDLE)?
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
From the ReleaseMutex() docs:While a thread has ownership of a mutex, it can specify the same mutex in additional wait-function calls without blocking its execution. This prevents a thread from deadlocking itself while waiting for a mutex that it already owns. However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I've never used templates very much even though I've been programming in C/C++ for many years. I have a class whith quite a few methods that have three arguments, like this:
int foo(int x, int y, char* string);
Now, I'd like to be able to generalize this a bit more so that it would do something like this:
int foo(int x, char* string);
or
int foo(int x, int y, int z, char* string);
One way, of course, to make the above just one function would be to rearrange to parameters, like this, and use varargs to extract the parameters:
int foo(char *string, ...);
I've been thinking that this may be a good candidate for a template. Instead of writing a class to take care of all possible combinations of parameters, it it possible to write a template class to handle it? If so, how would you rewrite the above lines ?
|
|
|
|
|
IMO, a template is best used when you have a function that can reasonably accept different types of parameters, but still maintain the same number and order of parameters:
template <class T> T is_clamp (T v, const T &L, const T &H)
{
if (v < L)
{
v = L;
}
else if (v > H)
{
v = H;
} return v;
}
this can handle any data type that supports "<", ">" and "=".
i think vararg is the best way to handle an arbitrary parameter list. templates don't really work that way - they can switch out parameter type in an argument list, but not order and position.
-c
Though the cough, hough and hiccough so unsought would plough me through,
enough that I o'er life's dark lough my thorough course pursue.
--Stuart Kidd
|
|
|
|
|
For some reason, some of my toolbar buttons/menu items are no longer hooked up to the view to be handled. I don't know what I did, but it just started happening. I've tried a few things to fix it like changing the ID of the resource and adding a new command message handler but that doesn't work either. any ideas as to what can cause this to happen or how to fix it?
|
|
|
|
|
Open file resource.h and ensure that all resource IDs are different.
|
|
|
|
|
I'd like to write some documentation for something & I'd like it to look current w/ msdn style documentation.... does anyone know of an html template suitable for documenting a software component? i suck @ making things look good w/ html and am hoping to find a dreamweaver template for such a purpose....
thanks!
Wes
Sonork ID 100.14017 wtheronjones
|
|
|
|
|
Hi!
I have some public functions in my class that simply need to return a private variable. Is it a good way to use the "inline" statement?
And what is it actually for? When is it suitable to use it?
Could someone explain me or post a link where it is described well? The MSDN documentation didn't really help me.
Thanks in advance
Greg
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Gregor S. wrote:
Is it a good way to use the "inline" statement?
No, that has nothing to do with it.
Gregor S. wrote:
And what is it actually for?
The idea of inline is you tell the compiler that a function is so small that it should be written
'in place' where it is called, rather than written once and then called via function calls. You can consider it similar to a macro, in that you write it once, but it gets expanded 'in place' where-ever you call it. Big caveat coming though.....
Gregor S. wrote:
When is it suitable to use it?
Whenever you have a very small function that you think will be called a lot and you want to improve performance.
Gregor S. wrote:
The MSDN documentation didn't really help me.
There's a surprise ) The M$ guys don't really know C++ that well, or at least that's what you'd think if you read MSDN for anything that is to do with the standard.
Speaking of which - the caveat. In the standard, inline is a SUGGESTION to the compiler, it is free to ignore you, and free to inline something itself if it feels it should. Therefore, there is almost no value in the inline keyword.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Thank you very much!
The only problem is: I didn't find caveat in my dictionary 
best regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I'm curious what suggestions you have for us regarding the documentation for inline?
"The compiler treats the inline expansion options and keywords as suggestions. There is no guarantee that functions will be inlined. You cannot force the compiler to inline a particular function, even with the __forceinline keyword."
It seems to me that the documentation is clear about inlining being a hint to the compiler. Reading further it discusses at length the Microsoft-specific extensions to inlining (__inline, __forceinline).
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
OK, I'm waving the white flag on this one. The Microsoft documentation on the STL is bloody awful, and it's on that basis that I presumed the original poster was right in saying the inline docs were not clear. On the face of it, it appears inline is documented pretty much the way I explained it....
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
We rewrote the STL documentation (and revamped the implementation of the library itself) for Visual C++ .NET 2002 specifically to address the "bloody awful"-ness of the 6.0 docs.
Is it still that terrible? Why? The docs aren't intended to teach the use of STL to a beginner, but most of our feedback says the docs are quite adequate for experienced developers.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Nick Hodapp (MSFT) wrote:
We rewrote the STL documentation (and revamped the implementation of the library itself) for Visual C++ .NET 2002 specifically to address the "bloody awful"-ness of the 6.0 docs.
I am aware of the legal hassles you guys had with your STL implimentation and from the brief chance I've had to use the new one, you've done a great job in fixing it up. I've never had a need to read the new docs though, I've used it only on a legacy app, I mainly code C# at home and we still use VC6 at work.
Nick Hodapp (MSFT) wrote:
Is it still that terrible?
I presume not, based on how good the actual STL implimentation seems to be.
Now if Microsoft would only pull it together and fix partial template specialisation ( and would Koenig namespace lookup be too much to ask for ? ). Do you have any idea when the pts is happening ?
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
Partial Template Specialization and a slew of other ANSI/ISO C++ conformance features are in the works. Stay tuned.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
AFAIR the VC7.1 compiler update was promised for this summer I also talked to people who already use a pre-release version and told me they are quite happy with it (it compiles Blitz++ and Loki!).
Can you give us any estimation when this cool thing is shipped to waiting masses?
It would be the real reason to switch to VStudio.Net... 
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
Like "in the works" would help us when we've been waiting since 1998?!
Sorry, but I couldn't resist it, not to mention you (Micros~1) deserv it - and more.
|
|
|
|
|
Nick - I've got a question about the STL documentation - not about the presentation (which seems OK - personally, it's just I haven't used it much compared to the VC6 docs), but a techie question that was raised in comp.lang.c++.moderated earlier today - the STL documentation for containers (vector, list etc) contains the following in the description for the end() method:
'If the container is empty, the result is undefined'
Is this actually true?! There's a requirement on containers in the C++ Standard that begin() == end() for empty containers - and that's what your implementation does... There's nothing on the Knowledge Base if it is an error in the docs...
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Ah hah, this _is_ confusing! The documentation for vector::end() reads:
Return Value
A pointer to the end of the vector object. If the vector is empty, the result is undefined.
This entire statement is misleading and I'll submit it as a bug. The iterator of a std::vector is no longer the same as a pointer. But an empty vector does satisfy begin() == end(). In our implementation, end() actually points to 0 internally when the vector is empty.
This posting is provided “AS IS” with no warranties, and confers no rights. You assume all risk for your use. © 2001 Microsoft Corporation. All rights reserved.
|
|
|
|
|
Hadn't even picked up on the pointer bit  - hadn't realised that your vector (and string, for that matter) iterators weren't pointers any more - still, I had made the correct assumption that the docs were wrong, not the code  (but not before tracing through the code in the debugger).
BTW - I presume the bug report indicts the documentation for all the container types - as I said before, the statement about the results of end() being undefined for an empty container is made in the documentation for each and every container type<edit>but not the basic_string class - but then that's not totally one of the container family</edit>.
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
