|
yes, everything seems to be working i have proper returns from the functions. it is just that my image is scrambled on the screen.
|
|
|
|
|
I know if you use int xxx= SetStretchBltMode(hdc,HALFTONE);.
you must change to brush origin with SetBrushOrgEx.
- God bless the World
|
|
|
|
|
I'd do some tracing in the debugger.
You never check your return values... one of these might help identify the problem.
It's hard to tell with only this code, but I'm not 100% about your CreateBitmap call... is Image (void *) valid? where does it come from. Also, you say that your image data is 1 bit per pixel. is it really? or is it 1 byte per pixel? you'd get a "scrambled" picture if this was wrong.
Just some ideas. it's hard to tell whats going on unless you post more code.
Also, things to try that will help debug are replacing strechblt with bitblt, does it work then? then, try stretchblt, but set dest size = to source size, what happens then?
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
You have several problems.
1) You do a DeleteObject(hrgn) without selecting the original region back into to the dc. You need to do a process similar to the bitmap where you store the old value and pump it back in before deleting it.
2). You are not creating a bitmap that is compatible with the dc. You create a compatible dc based off the screen (more than likely > 8 bit color depth) but go on to create a monochrome bitmap. If you need a monochrome bitmap in the end, create a bitmap that matches the dc, but then convert it down to monochrome afterwards.
If you have any further questions, let me know.
Joel Lucsy (jjlucsy@concentric.net)
|
|
|
|
|
Hi
I want to write a standard DLL without MFC support.
My question is, if it is possible to catch messages inside the DLL.
I need to catch WM_DDE_ACK and also set a timer to work inside the DLL.
Is this possible?
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I don't know if you can do it with messages but a timer can you start/handle in a DLL.
If you have the timer proc in the DLL.
------------------------------
©0d3 ©®4©k3® - That's me! 
------------------------------
|
|
|
|
|
My question is, if it is possible to catch messages inside the DLL.
Sure it is. Windows messages are of one of these two types:- Messages sent to a window (see
SendMessage),
- messages sent to a thread (see
PostThreadMessage)
Both types of messages are handled similarly by a so called message loop, executed within the thread that created the destination window (case 1) or the destination thread (case 2). The only difference when it comes to the message loop is that the hwnd parameter of the MSG structure received is 0 for messages of the second type.
All of this implies two things:- A responsive window must be created in the context of a thread that performs a message loop: deep deep inside the MFC code there's such a loop that causes your MFC windows to become alive. Without MFC, it's up to you to write the thing.
- If you're trying to catch a message intended for a window that has not been created by the current thread, then you're out of luck.
I'm not going to give you full details here on how to write a message loop thread, but its main code goes more or less like this:
MSG msg;
while(GetMessage(&msg,NULL,0,0)!=0){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
return;
The message loop keeps looping till GetMessage returns zero, which happens upon reception of a WM_QUIT message intended to the thread (see PostQuitMessage for more details).
So, to be able to catch Windows messages inside your non-MFC DLL you will have to set up a message loop thread (possibly with some dependent window) and write also the code to terminate that thread with PostMessage. Lots of fun ahead! Good luck!
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Great!!!
Thanks a lot!
regards 
modified 12-Sep-18 21:01pm.
|
|
|
|
|
For some reason, when I try to open a file in my application, I get an error and my application terminates. It's confusing because I haven't touched any of the code that is used to start the open file dialog and open the file. What's happening is it seems to be passing garbage data to the open file dialog that is longer than the maximum allowable length of data and it is crashing on an assertion. Has anyone encountered this problem or know what I'm talking about and have any idea on how to fix it?
|
|
|
|
|
Post the code where the problem is occuring. I can't think of any known problems but maybe we'll be able to spot something in the code.
Michael
|
|
|
|
|
Here is where the breakdown starts:
void CDocManager::OnFileOpen()
{
// prompt the user (with all document templates)
CString newName;
if (!DoPromptFileName(newName, AFX_IDS_OPENFILE,
OFN_HIDEREADONLY | OFN_FILEMUSTEXIST, TRUE, NULL))
return; // open cancelled
AfxGetApp()->OpenDocumentFile(newName);
// if returns NULL, the user has already been alerted
}
What's happening is the newName variable is getting a piece of data in it that is in one of my dropdown boxes. It's confusing because it has the data in it immediately after the variable declaration statement is executed. So, right after "CString newName;", the newName variable has some data in it and that seems to be the cause of the problem. I'm not sure how the data is getting there or why it is there right after the variable is declared, but... Any thoughts?
|
|
|
|
|
I have had this happen before, and it was usually a header file mismatch, which lead to a binary mismatch, or a debugging info mismatch.
The header files used to build the app do not match the LIBs and/or DLLs used to link and run the app. If your project builds/uses a few different custom DLLs, then there may be a mismatch between the ones that you have, and the ones that your app is expecting to import from at runtime.
A mismatch in your debugging information would cause your editor's "current instruction" pointer to point to code that you are not actually in.
Peace!
-=- James.
|
|
|
|
|
Hi,
I have got a problem with a popup menu that I have created in a CDialogBar.
The menu item is grayed out when the menu is displayed.
I use the same approach for some buttons, but there the menu item is enabled.
Am I doing something wrong, or is there a way to enable the menu item?
Cheers,
/Fredrik
Do you Sonork? I do! 100.11430:PhatBoy
|
|
|
|
|
That could probably be because the menu-item handlers dont exist in the context. Like perhaps you have put them in a view, which is not valid when you show the popup menu, as the focus is on the control bar. Try putting the handlers in the frame window class
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
It works if I put the handler in the frame window class, although I do not quite understand why.
What I am trying to do, is to encapsulate the menu item handler in my derived toolbar class. I handle the WM_RBUTTONDOWN message in the toolbar class to display the menu.
How do I do everything from the toolbar class?
Cheers,
/Fredrik
Do you Sonork? I do! 100.11430:PhatBoy
|
|
|
|
|
Fredrik Skoog wrote:
It works if I put the handler in the frame window class, although I do not quite understand why
Because, by default, if you do not setup an ON_COMMAND* handler for a command, it will be disabled. You also might want to look into how command routing works, so as to understand the order that is used when searching for a Command Handler.
Peace!
-=- James.
|
|
|
|
|
Why the functions GetWindowsDirectory(), GetSystemDirectory() and GetTempPath() failed on Windows XP? The returned folders are 'c:\abc', 'c:\abc\system\123' and 'c:\abc\temppath\123'
|
|
|
|
|
Gosh!!
That is sure funny! 
I am sorry, I can't help you there as I havent used XP yet.
But couldnt resist posting this one as I am laughing so hard my stomach muscles hurt
Nish
p.s. do those directories exist? or are they just fantastically made u?
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Of course they don't exist...
|
|
|
|
|
Then there is something wrong with your code or perhaps some virus has totally messed up your machine
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Looks like the children-version of XP 
For kids just learning the aplhabet and counting until 20
modified 12-Sep-18 21:01pm.
|
|
|
|
|
|
I tried this eagerly anticipating the results, but was disapointed to find my Windows XP installation does not share yours sense of humor:
E:\WINDOWS
E:\WINDOWS\System32
E:\DOCUME~1\Joshua\LOCALS~1\Temp\
Post the code you used, or the smallest possible snippit that illustrates the effect you're getting, pls.
farewell goodnight last one out turn out the lightsSmashing Pumpkins, Tales of a Scorched Earth
|
|
|
|
|
The code is listed below. I think there are no tricks to use these functions. If you wish I may send you a jpg screen shot of Microsoft Visual C++ 6.0 (Service Pack 5) in a debug session showing the value of variable 'szdir' after call GetSystemDirectory()...
I am sure I am not crazy... 
I am using "Microsoft Windows XP Professional( Build 2600 )", with AVG 6.0 Anti-Virus System resident (Virus Database 174, Release Date 2/1/2002)
CString sWindowsFolder,
sSystemFolder,
sTempFolder;
char szDir[ MAX_PATH ];
GetSystemDirectory( szDir, sizeof( szDir ) );
sSystemFolder = szDir;
GetWindowsDirectory( szDir, sizeof( szDir ) );
sWindowsFolder = szDir;
GetTempPath( sizeof( szDir ), szDir );
sTempFolder = szDir;
|
|
|
|
|
What are the return values for the functions? Do they return the correct length, or do they return 0.
Michael
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
