|
master87 wrote: How can I get the Windows Standard Dialog Background color?
You can use GetSysColor with COLOR_BTNFACE.
Regards,
Nish
|
|
|
|
|
@toxcct <ironie>thx for the very helpful post. here we have of corse a windows forum and not a visual C++ forum 
I know but this doesn't work.
CString rgbcolors;
rgbcolors.Format("%d,%d,%d", GetRValue(COLOR_BTNFACE), GetGValue(COLOR_BTNFACE), GetBValue(COLOR_BTNFACE));
rgbcolors returns "15,0,0"
And thats black not the dialog gray. 
|
|
|
|
|
ow, that was my mistake...
now it works... 
COLORREF col = GetSysColor(COLOR_BTNFACE);
CString rgbcolors;
rgbcolors.Format("%d,%d,%d",GetRValue(col),GetGValue(col),GetBValue(col));
|
|
|
|
|
Do this :-
DWORD color = GetSysColor(COLOR_BTNFACE);
cout << (int)GetRValue(color);
cout << (int)GetGValue(color);
cout << (int)GetBValue(color);
Regards,
Nish
|
|
|
|
|
master87 wrote: here we have of corse a windows forum and not a visual C++ forum
Regards,
Nish
|
|
|
|
|
How to map a network on another one using C++ Builder 6?
|
|
|
|
|
See here.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
I'm using callback functions to get rtf strings in and out of CRichEditCtrl and I'm not happy with any I tried.
1. Works great until I try to get unicode string (SF_UNICODE) - if I do i only get the first letter of the string.
<br />
DWORD __stdcall MEditStreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)<br />
{<br />
CString *psBuffer = (CString *)dwCookie;<br />
if (cb < psBuffer->GetLength()) cb = psBuffer->GetLength();<br />
for (int i=0;i<cb;i++) {<br />
*(pbBuff+i) = psBuffer->GetAt(i);<br />
}<br />
*pcb = cb;<br />
*psBuffer = psBuffer->Mid(cb);<br />
return 0;<br />
}<br />
<br />
DWORD __stdcall MEditStreamOutCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)<br />
{<br />
CString sThisWrite;<br />
sThisWrite.GetBufferSetLength(cb);<br />
CString *psBuffer = (CString *)dwCookie; <br />
for (int i=0;i<cb;i++) {<br />
sThisWrite.SetAt(i,*(pbBuff+i));<br />
}<br />
*psBuffer += sThisWrite;<br />
*pcb = sThisWrite.GetLength();<br />
sThisWrite.ReleaseBuffer();<br />
return 0;<br />
}<br />
2. Tricky. No problems with UNICODE (at least not with unicode as such - it basicaly works from time to time)
<br />
static DWORD CALLBACK StreamOut( DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb )<br />
{<br />
<br />
char* buff;<br />
buff = new char[ cb + 1 ];<br />
buff[ cb ] = ( char ) 0;<br />
strncpy( buff, ( LPCSTR ) pbBuff, cb );<br />
int max = strlen( buff );<br />
<br />
CString* str = ( CString* ) dwCookie;<br />
<br />
#ifdef _UNICODE<br />
<br />
int length = ::MultiByteToWideChar( CP_UTF8, 0, buff, max, NULL, 0 );<br />
if( length )<br />
{<br />
TCHAR* wBuff = new TCHAR[ length ];<br />
::MultiByteToWideChar( CP_UTF8, 0, buff, max, wBuff, length );<br />
*str += wBuff;<br />
delete[] wBuff;<br />
}<br />
#else<br />
*str += buff;<br />
#endif<br />
delete[] buff;<br />
*pcb = max; <br />
return 0;<br />
}<br />
and 'bout 2-3 found over net - none of them works as I'd like it to.
If you have a WORKING, TESTED callback functions for CRichEditCtrl and with unicode support let mi know. If you know what's wrong with these 2 sert and/or how to correct it just tell me
I apologise for any mistakes made in this post - it's my third day of non-stop coding and sleep depravation starts to kick in..
Maciej Lisiewski
The sad thing is that due to bad luck with code and deadlines my uptime makes me a good server.
-- modified at 9:49 Monday 9th January, 2006
|
|
|
|
|
Maciej Lisiewski wrote: DWORD __stdcall MEditStreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CString *psBuffer = (CString *)dwCookie;
if (cb < psBuffer->GetLength()) cb = psBuffer->GetLength();
for (int i=0;i *(pbBuff+i) = psBuffer->GetAt(i);
}
*pcb = cb;
*psBuffer = psBuffer->Mid(cb);
return 0;
}
The for has not been correctly transposed (the < got read as HTML tag, and the rest was ignored).
Anyway, I suppose you get the first char read in for some reason as non unicode (that's "the first letter of the string") and the second char, also read in as non unicode, and which should be the Unicode char second byte, terminates the string. So you get a string with only one char.
~RaGE();
|
|
|
|
|
I haven't got a clue why am I getting only the first char. It could happen with a unicode string read as single byte char string, but that's not the case. And it's true for every string I came up with, which, again, proves your theory wrong (I really wish it was that simple, I really do).
If anybody has any idea what's the problem - do write. Meanwhile I'll get myself an unhealthly large cup of coffee hoping to finish the code before my heart explodes 
More on the subject: if I stream rft into CRich.. as unicode (sf_rtf|sf_unicode) and read it as (sf_text) I get whole string with some characters replaced with '?', which is normal.
It it's (sf_rtf) in and (sf_text|sf_unicode) out I get just the first char (sligtly odd..)
(sf_rtf|sf_unicode) + (sf_text|sf_unicode) exacly the same.
Conclusion:
(sf_text|sf_unicode) = getting 1 char regardles of the string.
Could you look at the code please? I can't find the mistake (I hardly see anything being awake like 50 hours )
DWORD CALLBACK CAutoRichEditCtrl::CBStreamOut(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CString sThisWrite;
sThisWrite.GetBufferSetLength(cb);
CStringW *psBuffer = (CStringW *)dwCookie;
for (int i=0;i<cb;i++) {
sThisWrite.SetAt(i,*(pbBuff+i));
}
*psBuffer += sThisWrite;
*pcb = sThisWrite.GetLength();
sThisWrite.ReleaseBuffer();
return 0;
}
[..]
EDITSTREAM es;
es.dwError = 0;
es.pfnCallback = CBStreamOut;
CStringW theStringYouShouldBeLookingAt = _T(" ");
es.dwCookie = (DWORD) &theStringYouShouldBeLookingAt;
StreamOut(SF_TEXT, es); //(SF_TEXT|SF_UNICODE, es);
[..]
Maciej Lisiewski
Bioengineered coffee2code converter
-- modified at 12:58 Monday 9th January, 2006
|
|
|
|
|
Maybe a dumb question again, but what happens when you debug-run through
DWORD CALLBACK CAutoRichEditCtrl::CBStreamOut(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CString sThisWrite;
sThisWrite.GetBufferSetLength(cb);
CStringW *psBuffer = (CStringW *)dwCookie;
for (int i=0;i<cb;i++) {
sThisWrite.SetAt(i,*(pbBuff+i));
}
*psBuffer += sThisWrite;
*pcb = sThisWrite.GetLength();
sThisWrite.ReleaseBuffer();
return 0;
}
Where does it go wrong ?
~RaGE();
|
|
|
|
|
Hello Everybody
I am getting the user input using "stdin" from a seperate thread running in application "ABC". The problem I am facing is that when the application "ABC" is finished and user didnt enter any input than a deadlock is created between stdin and fflush. because "stdin" is still running in the thread and "fflush" is called by OS when it is terminating the program even I am terminating the threads explicitly. I am facing the same problem on AIX.
Any body have any idea that how can i remove deadlock.
Secondly How can I get the control back from "stdin" or how can i call "stdin" in non blocking mode.
Thanx in advance for your help and suggestions
Best Regards
Moin
|
|
|
|
|
Hello everyone,
I am currently in the progress of enhancing a software which my predecessor designed.
One of the caveats the software has: If there is an error, the software calls a "setErrorMessage"-Function to publish the error to the user. The same is true for warning messages, only that warning messages are collected until the called function either finished or hits an error.
Thats pretty ok for me, I dont think I would have chosen another approach.
Well, what makes this a bad design is that the setters are - each and every time - called with the text for the warning message as an argument.
There are SEVERAL messages that just get repeated all over the software, most notably a "nothing to process"-message, which is set in about 52 different locations, with different spelling, different capitalization, different wording... you name it, its probably in there.
So, I want to replace this with an error lookup table, passing a single number and setting the corresponding error message.
I have, so far, thought of several approaches to do this.
Common ground: I would be overloading "setErrorMessage(const std::string& msg)" with another function "setErrorMessage(const int msgID)" in order to maintain compatibility (there are client-made libs using this functionality).
What I am having a hard time with is selecting a fast and reliable way to store the messages and their IDs.
Any help, ideas, suggestions? Everything is welcome
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Sebastian Schneider wrote: What I am having a hard time with is selecting a fast and reliable way to store the messages and their IDs.
What's wrong with the string table?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Sebastian Schneider wrote: What I am having a hard time with is selecting a fast and reliable way to store the messages and their IDs.
What about the string table in the resource file ?
[Edit] Nevermind, your question was on the last line on my browser and David's answer was on the next page as I answered, so I did not see it. At least, we answered the same ... :-> [/Edit]
~RaGE();
|
|
|
|
|
If you used the Message Tables instead of the string table in the resourcs, then you could use the message compiler, have unique message/error identifiers, and even use FormatMessage API to format your errrors. They could go to the Windows Event Viewer too.
Another advantage of this is your error strings are in a separate DLL (they should be) and it is easier to localize your applciaiton's error strings - just trade out a DLL - no code changes required or rebuild of your main product.
Marriage slows down your coding, a baby slows it down even more!
|
|
|
|
|
And its so easy. I just totally forgot. Its been such a long time since I had to deal with any errors in my software... *cough*
Cheers
Sebastian
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Hi Friends,
I have developed a dialog based MFC programm. I want to read a text file which contains some encrypted characters....File may be long or may be short.
My problem is I don't know how to read that whole file as right now I use fread() functions to read file in which it terminates when it gets some character even if there are still more data in file. Also I tried to read it using a character by character reading by fgetc(). Still I encounter the same problem.
Is there a way to read whole file till the end of file. And all characters are read. Any function or any example ?
Thankx in advance.
Mahesh
|
|
|
|
|
Amarelia wrote: I use fread() functions to read file in which it terminates when it gets some character even if there are still more data in file
fread() reads a specified number of bytes, and doesn't look at the characters at all:
// read 100 bytes
FILE *fp = fopen(filename, "rb");
BYTE buf[100];
int read = fread(buf, 1, 100, fp);
fclose(fp);
if you want to read the whole file, just keep calling fread(..) until it returns 0 (no bytes read).
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
i think you problem may come from you write in a buffer not large enough.
do this :
1. get the number of characters in the file to be exctracted.
2. allocate your buffer with that number of bytes.
3. read() the totality of the file ; it will never overflow the buffer (considering the memory is correctly allocated)
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VisualCalc 3.0]
|
|
|
|
|
Amarelia wrote: ...it terminates when it gets some character...
Is it encountering an EOF character? If so, you need to open the file as binary, not text.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Hello,
Can anyone send me a link to a c++ sample that is able to track all pages sent to a local or network printer from a machine (running Windows XP)?
Thank you,
Regards,
Dan.
|
|
|
|
|
Start here.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
|
I think micutzu would benefit more from this suggestion.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
