|
Well, without seeing your code it's hard to say...try finding out if your 'cleanup code' really gets called or not by placing breakpoints, or TRACE-es, or a message box, or or or...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
Here is the section I am having problems with:
This is in a function of it's own:
Instead of using WindowFromPoint I am using hWnd that I have for the window
I am after since the user could have moved it.
POINT Textpt;
Textpt.x = a;
Textpt.y = c;
HDC DlgDC,MemDC,DeskDC;
int height, width;
HBRUSH hBrush;
HBITMAP hBitmap;
DlgDC = GetDC(hWnd);
DeskDC = GetDC(NULL);
hBrush = CreateSolidBrush(RGB(255,25,0));
width= 53;
height= 8;
MemDC = CreateCompatibleDC(DlgDC);
hBitmap = CreateCompatibleBitmap(DlgDC,width,height);
SelectObject(MemDC,hBitmap);
BitBlt(MemDC,0,0,width,height ,DeskDC,Textpt.x,Textpt.y,SRCCOPY);
////
Some processing....
Couple of If statements and geting color pixels.
////
after above is done processing->
ReleaseDC(NULL,MemDC);
DeleteObject(MemDC);
ReleaseDC(NULL,DlgDC);
DeleteObject(DlgDC);
ReleaseDC(NULL,DeskDC);
DeleteObject(DeskDC);
Please help if its wrong...
This is the only part that dies after 10 minutes. I ran this with the thread, I commented the rest of the app including the processing in between the above code.
I ran the thread own its own without the above it ran fine. All the thread was doing at that point was getting the handle to the window I am after.It ran for a long time.
Thanks a million.
|
|
|
|
|
This:
MemDC = CreateCompatibleDC(DlgDC);
must be "freed" like this:
DeleteDC(MemDC);
ReleaseDC does not need to be used for the memory DC, and DeleteObject is not for device contexts at all.
This:
DlgDC = GetDC(hWnd);
needs to be released like this:
ReleaseDC(hWnd, DlgDC);
ReleaseDC(NULL, DlgDC) is wrong, you need to specify the same window handle you used to get the DC. And once again, don't use DeleteObject for a DC.
Also note, when you select objects into a DC, may those be bitmaps or brushes or whatever, the original objects should be select back into the DC before you delete the DC or delete objects that were selected into the DC. To explain this a bit more clearly:
This is not complete:
HDC MemDC = CreateCompatibleDC(DlgDC);
HBITMAP bitmap = CreateCompatibleBitmap(MemDC, 100, 100);
SelectObject(MemDC, bitmap);
...
DeleteDC(MemDC);
DeleteObject(bitmap);
Should be done something like this:
HDC MemDC = CreateCompatibleDC(DlgDC);
HBITMAP bitmap = CreateCompatibleBitmap(MemDC, 100, 100);
HBITMAP originalbitmap = (HBITMAP)SelectObject(MemDC, bitmap);
...
SelectObject(MemDC, originalbitmap);
DeleteDC(MemDC);
DeleteObject(bitmap);
If you do not follow this "rule", your program will leak GDI resources...
Also one very important thing you should know about threads is that fiddling with GUI objects in other than the GUI thread is strongly not recommended.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
thanks a million. I will change a few things and give it a try.
|
|
|
|
|
Same thing in about 15 to 20 minutes at least it took a bit longer. I have a question. I am trying to capture text from an external app. the text on the app is being populated with WM_PAINT. Not sure even if a WM_PAINT hook to this application will help. What are my choices if this keeps not responding to the route I have taken.?
|
|
|
|
|
Oh,I'm sorry, my english is poor, how to use the in-place editing of microsoft?
example: Microsoft Word and Microsoft Equation Eidtor(in the word), what do it? ,in the program use word
thank you
|
|
|
|
|
what are you talking about. You are in the wrong forum.
Yusuf
Oh didn't you notice, analogous to square roots, they recently introduced rectangular, circular, and diamond roots to determine the size of the corresponding shapes when given the area. Luc Pattyn[^]
|
|
|
|
|
Hi, I have a problem when I want to use de XP/Vista Styles for Common Controls. As I'm using Visual Studio 2008, at the beggining of the code I put:
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
I read in the MSDN it is not neccesary add a manifest if I include that (if I use a manifest in XP the controls disappeard but the program works), but when I execute the program in XP, i get a error message, something like "Reinstallation of the program could solve the issue", on the other hand, in Vista works fine and the controls have the Vista style. ¿What is wrong?
Thanks
|
|
|
|
|
Did you call InitCommonControlsEx[^]? Aside of that, i believe "Reinstallation of the program could solce the issue" you usually get when your program uses a DLL the system cannot find...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
|
After trying to create the dialog use GetLastError to find out why it did not get created. I have seen behaviour like that in at least 3 cases:
-the resource of the dialog did not exist, since you say it works fine under Vista i'd say that is not the case
-the dialog had some control on it which could not be created because its class was not registered, like custom controls we forgot to explicitly register before trying to brign up the dialog.
-usage of an ActiveX control on the dialog which was not registered on the system.
There might be tonns of other reasons of course...could it be that you are using some "special" control (ActiveX?) on your dialog that needs explicit registering under XP but it is registered already/by default under Vista?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
I've call GetLastError after create the dialog box, but it returns 0, and DialogBox returns -1. Looking at MSDN I saw 4 possible errors, althought none of them I think are the problem:
-an invalid parameter value
-the system class was registered by a different module
-The WH_CBT hook is installed and returns a failure code
-if one of the controls in the dialog template is not registered, or its window window procedure fails WM_CREATE or WM_NCCREATE
I don't understand why does not work, because the controls inside the dialog box are edit and buttons controls, only that. I put the code of the definition of the dialog box:
NewDialogBox DIALOGEX 170,70,250,150<br />
STYLE DS_MODALFRAME | WS_POPUP | WS_CAPTION | WS_SYSMENU<br />
CAPTION "Nuevo"<br />
FONT 10, "Tahoma"<br />
BEGIN<br />
DEFPUSHBUTTON "Aceptar", IDOK | WS_TABSTOP, 95, 130, 50, 14<br />
PUSHBUTTON "Cancelar", IDCANCEL | WS_TABSTOP, 165, 130, 50, 14<br />
CONTROL "Anchura", IDS_WEIGHT, "static", <br />
SS_LEFT | WS_CHILD | WS_VISIBLE, <br />
20, 50, 150, 8<br />
CONTROL "", IDE_WEIGHT, "edit", <br />
SS_LEFT | WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP, <br />
100, 50, 100, 12<br />
CONTROL "Altura", IDS_HEIGHT, "static", <br />
SS_LEFT | WS_CHILD | WS_VISIBLE, <br />
20, 70, 150, 8<br />
CONTROL "", IDE_HEIGHT, "edit", <br />
SS_LEFT | WS_CHILD | WS_VISIBLE | WS_BORDER | WS_TABSTOP, <br />
100, 70, 100, 12<br />
END
Thanks.
|
|
|
|
|
Hmm...did you try stepping thorough the code (during runtime i mean by setting a breakpoint and using "Step into" and such tools) to see where it fails? Does the dialog show if you remove the controls from it? If yes, maybe try putting them back one by one and see when the dialog stops showing...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <
|
|
|
|
|
No, I didn't try that, but when I can get a machine with XP, I'll debug it. Compiling the code with XP make the dialog box doesn't work, same problem that compiling it with Vista.
When I debug the code, I'll post the results.
Thanks.
EDIT: I've found the solution. As you said, we need to use the normal version of InitCommonControls at the beggining of the WinMain and link comctl32.lib and include the header commctrl.h. Putting the line:
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='X86' publicKeyToken='6595b64144ccf1df' language='*'\"") at the beggining of the file or including a manifest file all works fine in XP and Vista.
Thank you for all the help.
modified on Monday, March 23, 2009 5:26 PM
|
|
|
|
|
Hi,
Really im getting confused in using unicode in my project.....When im writing the code using ANSI it is working fine but when im writing code in Unicode im getting lot of errors....im confused with LPCWSTR,LPCSTR,LPWSTR,LPBYTE.....some functions take some of these as parameters but im really confused of using them, can i get any basic article to start with.....bcos lot of time wasted by just not knowing how to use these things....
suppose
CString csPath="D:\\test";
::CreateDirectory(csPath+_T("\\tester"),NULL);
the above code works fine in ANSI but gives errors in Unicode like
cannot convert parameter 1 from 'ATL::CStringT<BaseType,StringTraits>' to 'LPCWSTR'
how to convert CString to LPCWSTR or What parameter should i use in CreateDirectoryW() instaed of CString....
Please help me out.......
|
|
|
|
|
p_1960 wrote: Hi,
Really im getting confused in using unicode in my project.....When im writing the code using ANSI it is working fine but when im writing code in Unicode im getting lot of errors....im confused with LPCWSTR,LPCSTR,LPWSTR,LPBYTE.....some functions take some of these as parameters but im really confused of using them, can i get any basic article to start with.....bcos lot of time wasted by just not knowing how to use these things....
suppose
See here and here.
p_1960 wrote: CString csPath="D:\\test";
::CreateDirectory(csPath+_T("\\tester"),NULL);
Change to
CString csPath = _T("D:\\test");
csPath += _T("\\tester");
::CreateDirectory(csPath , NULL);
The fix occurs int the first line, the middle one is just a matter of style.
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]
|
|
|
|
|
There's two basic defines in the windows header files: CHAR and WCHAR. CHAR is defined as an ordinary char, and WCHAR is defined as a 16 bit WORD. CHAR is used for ANSI/MBCS (Multibyte character sets - pre-unicode solutions for "exotic" languages). WCHAR is used for UTF16/Unicode.
To assign an ANSI character, you do as you are used to. CHAR c = 'A'; To assign a Unicode character, you do it like this: CHAR u = L'A'; The L prefix tells the compiler that the character is a Unicode character. The same pattern applies for strings.
Strings are defined like this in the header files:
typedef LPSTR char*;
typedef LPWSTR char*;
Here you can also see a pattern emerge in the string defines. Whenever you see a W in it somewhere, it's a Unicode string. If it's got a C in it (like LPCSTR), it's a const string.
To assign an Ansi string, you do something like this: LPCSTR str = "Hello world!"; Similarly in Unicode: LPCWSTR str = L"Hello world!";
With me so far?
Right. There's a third define in the windows header file which is a bit special. It's called TCHAR. TCHAR is defined like this:
#ifdef _UNICODE
typedef TCHAR WCHAR;
#else
typedef TCHAR CHAR;
#endif
The meaning of TCHAR is dependent on the _UNICODE symbol. When you specify in the project properties that you want to be using Unicode, the compiler will define this symbol for you.
Anyway, this is ideal if you want to support both ANSI and Unicode builds of the same application. There's just one problem though. This line: LPCTSTR str = "Hello world!"; will only compile in ANSI builds, but not in Unicode build. This is because the string in the example is of type LPCSTR (const char*), while str is of type LPCWSTR (const WORD*)1. The remedy are the macros _T() and TEXT(). _T and TEXT are equivalent. I prefer typing _T because it's less typing.
_T (and TEXT) are define like this:
#ifdef _UNICODE
#define _T(x) L##x
#else
#define _T(x) x
#endif
So, the previous code LPCTSTR str = "Hello world!" should be rewritten as LPCTSTR str = _T("Hello world!");. This will be expanded to the correct version, depending on wheter you've specified _UNICODE or not.
You will find that the Microsoft APIs have support for both Ansi and Unicode in parallel. In most cases (such as the Win32 API), the header files will define functions like this:
BOOL CreateWindowA(...);
BOOL CreateWindowW(...);
#ifdef _UNICODE
#define CreateWindow CreateWindowW
#else
#define CreateWindow CreateWindowA
#endif
This way, as long as you are consistent in the use of either Ansi or Unicode strings, you won't have to adapt much. Other APIs such as the C runtime library are a bit different. There you have the good old functions such as strlen left intact - they only work on ANSI strings. In addition to strlen, there is also wcslen (Unicode), and _tcslen. the _t-functions are defined differently depending on the _UNICODE symbol, much like the Win32 functions mentioned earlier.
The quick answer to your question is: Use _T() for all your strings and characters, and use _t-functions from the C runtime library, and you will be pretty much fine. Do remember though, that when you write text to sockets, files or via some other medium, that you might have to reencode your Unicode strings. That, however, is a bit larger topic...
Personally, I think it's best to just pick Unicode from scratch. The world is becoming more and more globalized, and different cultures meet more often, so in a business application, odds are that there will be "trouble" down the line. Windows is also a bit faster at handling Unicode strings, because starting with NT4 (or was it Windows 2000? can't remember), the Ansi-versions of the API functions are just shallow wrappers that converts the strings into Unicode and pass them onto the Unicode implementations.
1 The compiler in these errors complain that the types const char* isn't compatible with the type const unsigned short*.
|
|
|
|
|
MFC, STUDIO 2008,
Project use UNICODE
CString m_sTest;
m_sTest = L"Байкал";
char *m_pchar3;
m_pchar3 = new char[70];
How todo m_sTest into m_pchar3?
//- m_pchar3=m_sTest; // error C2440: '=' : cannot convert from 'CString' to 'char *'
//- strcpy(m_pchar3, m_sTest); // error C2664: 'strcpy' : cannot convert parameter 2 from 'CString' to 'const char *'
//- strcpy(m_pchar3, (TCHAR)m_sTest); // error C2440: 'type cast' : cannot convert from 'CString' to 'TCHAR'
//- _tcscpy( m_pchar3, (TCHAR*)(LPCTSTR)m_sTest ); // error C2664: 'wcscpy' : cannot convert parameter 1 from 'char *' to 'wchar_t *'
|
|
|
|
|
Why do you need to do that?
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]
|
|
|
|
|
CHIVOTIOV wrote: char *m_pchar3;
m_pchar3 = new char[70];
Use TCHAR instead of char.
|
|
|
|
|
The m_sTest is a UNICODE string. So if you want to convert this UNICODE string to char* use WideCharToMultiBye API or use CRT function wcstombs.
prvn
|
|
|
|
|
CHIVOTIOV wrote: / error C2664: 'wcscpy' : cannot convert parameter 1 from 'char *' to 'wchar_t *'
Just a padding to the other replies here. As the above lines says, You are trying to squeeze a 2 Byte string (UNICODE) into a single byte string(ANSI).
char , std::string , etc by default belong to the single byte representation.
wchar_t, std::wstring, etc represent UNICODE representation.
TCHAR is "neutral" based on the scheme used, it switches type accordingly. If you define # UNICODE in the setting, the string becomes 2 byte reps. If you don't define it, it becomes single byte. Also when you use TCHARs, you should use strings apis specific to TCHARs. (like _tcscpy) that assures complete independence to your character-set implementations.
Similarly, CString switches types based on the project character-set settings.(UNICODE/Single-byte).
Now you have defined UNICODE in your project settings but trying a cross-copy operation. So just figure out what needs to be done..
He never answers anyone who replies to him. I've taken to calling him a retard, which is not fair to retards everywhere.-Christian Graus
|
|
|
|
|
hi,
Can Anybody tell me how to write a list control data in text file in MFC?
|
|
|
|
|
CListCtrl has member functions like GetItem(), GetItemData(), etc., and there's CFile that you can use to write to file. Where exactly are you stuck?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Hi!
I have an array of pointers, which point to classes derived from the same class. I also have a pointer, that points to the array. Is there a simple way to find out to which element of the array this pointer points to, or shall i use a variable in the base class for this purpose?
Thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
