Hi, all!
To say the truth - I am at a deadlock :eek At work I have Windows XP - SP1, at home - SP2. There are two almost identical projects - just a window with button and click on button opens Open File common dialog. In the first project I used CreateWindowEx to create the main window and in second - DialogBoxParam for the same purpose. On SP1 both projects fly right. But on SP2 - the project with DialogBoxParam just crashes on each click and offers me:"Tell Microsoft about this problem" :bdg The projects are just the same except the method of main window creation. I tried to play with InitCommonControls and InitCommonControlsEx functions without any result.
Has anybody ever faced with such problem? May be this is just ordinal bug of SP2? Or just my own ordinal bug? :green
I attach the projects (they are realy very small - I have removed all the unnecessary things). May be somebody can take a glance. After all - I'm just a lamer...
[attachment deleted by admin]
That is very odd - I have made several programs using DialogBoxParam and they work fine under my SP2. I am unable to download stuff (damn school policies!) so please could you post the DialogBoxParam code?
The asm file:
.386
.model flat,stdcall
option casemap:none
include windows.inc
include kernel32.inc
include user32.inc
include comctl32.inc
include comdlg32.inc
includelib kernel32.lib
includelib user32.lib
includelib comctl32.lib
includelib comdlg32.lib
DialogProc proto :DWORD,:DWORD,:DWORD,:DWORD
OpenDialogProc proto :DWORD
.data
AppName db "Test Window",0
szFilter db "All files (*.*)",0,"*.*",0,0
szCaption db "Open File",0
.data?
CommandLine LPSTR ?
hInstance HINSTANCE ?
hButton HWND ?
.const
IDD_DLG equ 1000
IDC_BTN equ 1001
.code
Start:
invoke GetModuleHandle,NULL
mov hInstance,eax
invoke GetCommandLine
mov CommandLine,eax
;invoke InitCommonControls
invoke DialogBoxParam,hInstance,IDD_DLG,NULL,addr DialogProc,NULL
invoke ExitProcess,eax
DialogProc proc hWin:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM
mov eax,uMsg
.if eax==WM_INITDIALOG
.elseif eax==WM_COMMAND
mov edx,wParam
movzx eax,dx
shr edx,16
.if edx==BN_CLICKED
.if eax==IDC_BTN
invoke OpenDialogProc,hWin
.endif
.endif
.elseif eax==WM_CLOSE
invoke EndDialog,hWin,NULL
.else
mov eax,FALSE
ret
.endif
mov eax,TRUE
ret
DialogProc endp
OpenDialogProc proc hwnd:HWND
LOCAL opf:OPENFILENAME
LOCAL szFileName[256]:BYTE
LOCAL szFileTitle[256]:BYTE
mov opf.lStructSize,sizeof OPENFILENAME
lea ebx,szFileName
invoke RtlZeroMemory,ebx,256
mov opf.lpstrFile,ebx
mov opf.nMaxFile,255
lea ebx,szFileTitle
mov opf.lpstrFileTitle,ebx
mov opf.nMaxFileTitle,255
mov opf.lpstrFilter,offset szFilter
push hInstance
pop opf.hInstance
push hwnd
pop opf.hwndOwner
mov opf.lpstrTitle,offset szCaption
mov opf.Flags,OFN_EXPLORER Or OFN_HIDEREADONLY
invoke GetOpenFileName,addr opf
ret
OpenDialogProc endp
end Start
and two RC-s
#define IDD_DLG 1000
#define IDC_BTN 1001
IDD_DLG DIALOGEX 6,6,301,68
CAPTION "Test Dialog"
FONT 8,"MS Sans Serif",400,0
STYLE 0x10CC0000
EXSTYLE 0x00000000
BEGIN
CONTROL "Push",IDC_BTN,"Button",0x50010000,26,40,244,20,0x00000000
END
#define MANIFEST 24
1 MANIFEST DISCARDABLE "TestDialog.xml"
Manifest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly
xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.1.0.0"
type="win32"
name="TestWindow.exe"/>
<description>Mx XP Program</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="x86"/>
</dependentAssembly>
</dependency>
</assembly>
For me, it only worked if I put the OPENFILENAME in the data section. This is probably a bug in SP2.
There is an inconsistency between the MASM32 windows.inc version of the structure and the PSDK version.
OPENFILENAMEA STRUCT
lStructSize DWORD ?
hwndOwner DWORD ?
hInstance DWORD ?
lpstrFilter DWORD ?
lpstrCustomFilter DWORD ?
nMaxCustFilter DWORD ?
nFilterIndex DWORD ?
lpstrFile DWORD ?
nMaxFile DWORD ?
lpstrFileTitle DWORD ?
nMaxFileTitle DWORD ?
lpstrInitialDir DWORD ?
lpstrTitle DWORD ?
Flags DWORD ?
nFileOffset WORD ?
nFileExtension WORD ?
lpstrDefExt DWORD ?
lCustData DWORD ?
lpfnHook DWORD ?
lpTemplateName DWORD ?
OPENFILENAMEA ENDS
OPENFILENAME equ <OPENFILENAMEA>
typedef struct tagOFN {
DWORD lStructSize;
HWND hwndOwner;
HINSTANCE hInstance;
LPCTSTR lpstrFilter;
LPTSTR lpstrCustomFilter;
DWORD nMaxCustFilter;
DWORD nFilterIndex;
LPTSTR lpstrFile;
DWORD nMaxFile;
LPTSTR lpstrFileTitle;
DWORD nMaxFileTitle;
LPCTSTR lpstrInitialDir;
LPCTSTR lpstrTitle;
DWORD Flags;
WORD nFileOffset;
WORD nFileExtension;
LPCTSTR lpstrDefExt;
LPARAM lCustData;
LPOFNHOOKPROC lpfnHook;
LPCTSTR lpTemplateName;
#if (_WIN32_WINNT >= 0x0500)
void * pvReserved;
DWORD dwReserved;
DWORD FlagsEx;
#endif // (_WIN32_WINNT >= 0x0500)
} OPENFILENAME, *LPOPENFILENAME;
What is _WIN32_WINNT?
And why should it make a difference, whether ofn is in the stack or in the data?
And why does it works fine when I use CreateWindowEx instead of DialogBoxParam? May be there is a problem with dialog boxes under SP2?
MichaelW,
Since I have a WINNT machine, adding those 3 declarations to the structure in windows.inc should solve the problem if you are correct. Unfortunately, this is not the case, adding to the structure does not solve the problem.
Lamer,
I am inclined to agree with you unless someone comes up with a better explanation.
Aero,
Sometimes you ask unusual questions. It is obvious that it is testing to see if it is running on 'NT' :lol
This is very interesting to me as it might explain some other problems I have had.
Paul
lamer: This is freaking me out. I can't understand it. As a workaround, you will have to put opf in the data? section.
Paul: I disagree. Firstly, why 500h? Secondly, where is it defined and what exactly does it measure?
Aero,
It is not being used by your version of windows.inc, there are lots of docs that answer your question. You evidently need to learn. As far as 500h goes, it is actually testing (in the 'C++ implementation) for 'NT' as defined by 5.00 which is the numerical version of 'NT'
This is very basic stuff you need to learn in order to program correctly, if you have more questions, I, or others, will be happy to answer them. In the interim, just don't flatly 'disagree' with what you do not know...
Quote from: pbrennick on May 05, 2005, 09:35:32 AM
You evidently need to learn.
That is why I asked.
Quote from: pbrennick on May 05, 2005, 09:35:32 AM
In the interim, just don't flatly 'disagree' with what you do not know...
I was disagreeing with your claim that it was obvious.
Quote from: pbrennick on May 05, 2005, 09:35:32 AM
This is very basic stuff you need to learn in order to program correctly
I have managed perfectly well so far without knowing it.
Aero,
You will go far and I think you know that I like you. Just trying to help. It is okay to question everything but when you say you disagree then I have to respond. I forget that some of this stuff is not 'obvious' to everyone so I should not have said that.
Have fun,
Paul
Quote from: AeroASM on May 05, 2005, 09:22:32 AM
This is freaking me out.
You are not alone :dazzled:
Unfortunately I can't test this all at work - there is SP1 only on my computer and some boring jobs.
By the way, I have found that GDI+ does not work, when call it from modal dialog.
But this is another story...
Anything defined in the .data section gets initialized to zero - unless you specify another value. On the other hand, any local variables are NOT initialized to any value (unless you add some MOVs to your code), instead they will just contain anything that was already on the stack. Since on latter Windows version the OPENFILENAME structure got updated, maybe you're not initializing the new members. Try calling RtlZeroMemory to initialize your structure before filling it, and see if it works.
QvasiModo,
Waw! Great! It works! :clap:
I can't believe it! With old structure! Guys, initialize all! Applause!
Quote from: lamer on May 05, 2005, 02:50:02 PM
By the way, I have found that GDI+ does not work, when call it from modal dialog.
But this is another story...
And this began to work as well!
Where have you been before?! :thumbu
What are you on about? In the faulty code, he Does use RtlZeroMemory!
Quote from: lamer on May 05, 2005, 08:56:16 PM
QvasiModo,
Waw! Great! It works! :clap:
I can't believe it! With old structure! Guys, initialize all! Applause!
Quote from: lamer on May 05, 2005, 02:50:02 PM
By the way, I have found that GDI+ does not work, when call it from modal dialog.
But this is another story...
And this began to work as well!
Where have you been before?! :thumbu
:bg :bg :bg
Glad to know it's working now! :U
Quote from: AeroASM on May 05, 2005, 08:58:34 PM
What are you on about? In the faulty code, he Does use RtlZeroMemory!
Look closer, he was using RtlZeroMemory only on the filename buffer.
Aero,
You are doing it again... :boohoo:
QvasiModo,
You rock, I did not realize that local variables are uninitialized or else I just forgot. I always zero these veriables in my code as a matter of course so it slipped by me being someone else's code. Anyway, very timely posting, dude!
Paul
I would either remove the use of EBX or properly preserve EBX in either the DialogProc or the OpenFileProc.
Quote from: pbrennick on May 05, 2005, 09:13:33 AM
MichaelW,
Since I have a WINNT machine, adding those 3 declarations to the structure in windows.inc should solve the problem if you are correct. Unfortunately, this is not the case, adding to the structure does not solve the problem.
Hi Paul,
I was not suggesting that this was the cause of the problem, just that there was an inconsistency that should be investigated (I should have made that clear). I did notice this in the PSDK documentation:
Quote
lStructSize
Specifies the length, in bytes, of the structure.
Windows NT 4.0: In an application that is compiled with WINVER and _WIN32_WINNT >= 0x0500, use OPENFILENAME_SIZE_VERSION_400 for this member.
Windows 2000/XP: Use sizeof (OPENFILENAME) for this parameter.
And then from CommDlg.h:
#ifndef CDSIZEOF_STRUCT
#define CDSIZEOF_STRUCT(structname, member) (((int)((LPBYTE)(&((structname*)0)->member) - ((LPBYTE)((structname*)0)))) + sizeof(((structname*)0)->member))
#endif
#if (_WIN32_WINNT >= 0x0500)
#define OPENFILENAME_SIZE_VERSION_400A CDSIZEOF_STRUCT(OPENFILENAMEA,lpTemplateName)
#define OPENFILENAME_SIZE_VERSION_400W CDSIZEOF_STRUCT(OPENFILENAMEW,lpTemplateName)
#ifdef UNICODE
#define OPENFILENAME_SIZE_VERSION_400 OPENFILENAME_SIZE_VERSION_400W
#else
#define OPENFILENAME_SIZE_VERSION_400 OPENFILENAME_SIZE_VERSION_400A
#endif // !UNICODE
#endif // (_WIN32_WINNT >= 0x0500)
But I'm not sure what sizeof (OPENFILENAME) would return. The MASM32 structure is 76 bytes. Would the PSDK structure be 76 or 88 bytes? Or just test both values?