|
Are you sure the error is there? Maybe some other obscure problem is causing this. try debugging and trace through the valid code areas. If still unsuccessful, try posting some code snippets
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
Thanks Nish, it was indeed a stupid programming mistake which Win98 doesn't care about but win 2000 does..
|
|
|
|
|
Hi,
I created an InProcServer(ToolBand.dll) on my Windows NT Wkts which works fine for NT Server4.0, Win98, 2K, and Me. This doesn't get installed on the setup of Win95 running IE5. I get error message "This function is only valid in Win32 mode". There were some "Ex" Registry API used in DllRegiserServer(). I've replaced it with normal API's i mean without "Ex", but the problem remains same. I get same error message with RegSetValue(..) API. Is there any compatibility issue?
It seems that Windows 95 is not pure win32. Hey Any comments? Why its so ironical behaviour? Should I need to build this application on VC++ running on Windows 95? I there any registry key or service to get some Win32 services on Win95.
I'm fed-up with this behaviour. Help me with any comments.
--Sumit
|
|
|
|
|
Sumit PAndya wrote:
It seems that Windows 95 is not pure win32.
Yep. Win95/98/ME do not support the complete Win32 API. Much of the Unicode-versions of functions are flat-out missing, others are partially implemented (and will return the error you mention), and a few are implemented fully for COM use.
It sounds like you are using an NT-or-greater-only function in your code. Take another look at the bottom of the MSDN help pages for information on what platforms support what functions.
You can also put
<br />
#define _WIN32_WINDOWS = 0x0410<br />
#define WINVER = 0x0400<br />
- Before all other includes in your StdAfx.h file to help check what functions you are using. (Look up those identifiers in MSDN for more information.)
Peace!
-=- James.
|
|
|
|
|
Hi,
It is a surprise knowledge that Win95 is not pure Win32 OS. Thanks for this information. Hey anyway I defined those system-variables but it didn't helped me out. I've verified all the API's and its documented for Win95 and later so as far documentation is concern there is no issue of lacking support. But Do you believe in M$ Documents  ? Personally I never, I've many bad experiences with false commitment and wrong information in documentation from M$. The main surprise for me is error in Registry API call, RegCreate..., which i've used in many of my softwares and was not creating any problem in those. But it stucked up in this development and with previously used API's but those were normal application and this is COM.... Grrrrrr....
Let me notify if you have another suggession on this.
Regards,
--Sumit
|
|
|
|
|
Sumit Pandya wrote:
The main surprise for me is error in Registry API call, RegCreate...,
Please specify exactly how you are calling the failing function, what parameters you are passing in to it, and the total length of any string parameters.
Peace!
-=- James.
|
|
|
|
|
As "Collaboration/Testing" is a section that doesn't receive much attention, I'm taking the liberty to insert here a little ad for a post of mine I've just sent there (click here to go). It requests a little help from you all about a weird behavior in Windows 2000 that seems to me to be a bug and is driving me nuts.
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
with the below code all i see is a scrambled image. i used the same code in watcom c++ and it seemed to work ok. I am now using msvc++.
i am not sure if i am doing something wrong or if i have to change the functions to microsoft standards.
HDC ScanImageDC, hdc, Oldhdc;
HBITMAP ImageBitmap, OldImageBitmap;
HRGN hrgn;
hdc = GetDC(NULL);
Oldhdc = hdc;
hrgn = CreateRectRgn(0, 0, 800, 600);
SelectObject(hdc, hrgn);
FillRgn(hdc, hrgn, (HBRUSH) CreateSolidBrush(RGB(255, 255, 255)));
DeleteObject(hrgn);
ImageBitmap = CreateBitmap(imgwth,imghth, 1, 1, Image);
ScanImageDC = CreateCompatibleDC(hdc);
SetBkMode(ScanImageDC, OPAQUE);
OldImageBitmap = SelectBitmap(ScanImageDC, ImageBitmap);
int xxx= SetStretchBltMode(hdc,STRETCH_HALFTONE);
StretchBlt(hdc, 0, 0, 800, 600, ScanImageDC, 0, 0,imgwth,imghth, SRCCOPY);
SelectBitmap(ScanImageDC, OldImageBitmap);
DeleteDC(ScanImageDC);
DeleteObject(ImageBitmap);
|
|
|
|
|
Did you release the DC?
- God bless the World
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
