- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
If I show a dialog box using DLGMODAL I am unable to use the system generated routine CenterWindow to centre it on the screen. This is one of the ways I've tried:
bret = dlginit(IDD_PROD,dlg)
call CenterWindow(Dlg.hWnd,GetWindow(Dlg.hWnd,GW_OWNER))
but nothing happens - the dialog always displays in the top left corner. I guess this is just a beginner's dumb question, but what am I doing wrong?
Many thanks
Mike (Perth, Western Australia)
bret = dlginit(IDD_PROD,dlg)
call CenterWindow(Dlg.hWnd,GetWindow(Dlg.hWnd,GW_OWNER))
but nothing happens - the dialog always displays in the top left corner. I guess this is just a beginner's dumb question, but what am I doing wrong?
Many thanks
Mike (Perth, Western Australia)
コピーされたリンク
8 返答(返信)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
The problem is that the dialog exists only during the call to DlgModal -- Dlg%hWnd is zero before that. Thus, any API routine that takes dialog handle as an argument will work only when called from a callback routine.
You should define a "dialog-initialization" callback, which is called immediately after DlgModal is entered:
As a simpler way, there's "Center" checkbox on "More styles" tab of dialog properties. However, that always centers the dialog relative to the screen, not to the owner window.
Jugoslav
You should define a "dialog-initialization" callback, which is called immediately after DlgModal is entered:
external OnDlgInit bret = DlgInit(IDD_PROD, Dlg) bret = DlgSetSub(Dlg, IDD_PROD) ... subroutine OnDlgInit(Dlg, ID, iEvent) ... call CenterWindow(Dlg.hWnd,GetWindow(Dlg.hWnd,GW_OWNER)) end subroutine OnDlgInit
As a simpler way, there's "Center" checkbox on "More styles" tab of dialog properties. However, that always centers the dialog relative to the screen, not to the owner window.
Jugoslav
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Thanks very much for that - it works nicely. Can the method be extended to cater for such things as the Open file dialog? ...
...
type (T_OPENFILENAME)Ofn
...
!Activate OpenFile dialog
bret = GETOPENFILENAME(Ofn)
It must be possible, but I can't see how.
Many thanks again,
Mike
...
type (T_OPENFILENAME)Ofn
...
!Activate OpenFile dialog
bret = GETOPENFILENAME(Ofn)
It must be possible, but I can't see how.
Many thanks again,
Mike
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Yes it is, using the similar principle -- OPENFILENAME%lpfnHook member can point to a user-defined callback function (if Flags member contains OFN_ENABLEHOOK).
My XGetOpenFile wrapper (part of XFT Lite library) does that by default. Usage is as simple as (there's documentation in .chm format as well):
Jugoslav
My XGetOpenFile wrapper (part of XFT Lite library) does that by default. Usage is as simple as (there's documentation in .chm format as well):
CHARACTER(260), SAVE:: sDir = "" CHARACTER(64):: sFile sFile = "" IF (XGetOpenFile(hFrame, sDir, nFiles, sFile, & sExts=(/"*.dat"/), sTypes=(/"Data Files (*.dat)"/))) THEN OPEN(42, FILE=TRIM(sDir)//""//sFile) ...
Jugoslav
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Many thanks, Jugoslav, that works fine. My only problem now is the fact that my open file dialog is of the old style, whereas before, when I couldn't centre it, it was the explorer style. I'm intrigued to know why it would change. I have experimented with OFN settings as follows:
Ofn%FLAGS = IOR(OFN_ENABLEHOOK,OFN_EXPLORER)
and this does give a version of the explorer dialog, but it will not be centred, whereas with
Ofn%FLAGS = OFN_ENABLEHOOK
the old style dialog is centred.
I would appreciate any insights.
Thanks again
Mike
Ofn%FLAGS = IOR(OFN_ENABLEHOOK,OFN_EXPLORER)
and this does give a version of the explorer dialog, but it will not be centred, whereas with
Ofn%FLAGS = OFN_ENABLEHOOK
the old style dialog is centred.
I would appreciate any insights.
Thanks again
Mike
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
That's because the hook behaves differently depending on presence of OFN_EXPLORER flag. See "OFNHookProc" and "OFNHookProcOldStyle" entries in SDK Help. Briefly, hWnd argument of "old style" hook (without OFN_EXPLORER) is the "Open" dialog itself. For "new style" hook the hWnd is handle of a child dialog of "Open" dialog -- use GetParent(hWnd) to get the handle of main dialog itself.
The change was introduced because now you can customize the dialog by adding a child dialog of your own. See for example CVF's Open dialog -- it has a checkbox and a combo added at the bottom; they're placed on a borderless child dialog which is a child of the "Open" dialog.
Jugoslav
The change was introduced because now you can customize the dialog by adding a child dialog of your own. See for example CVF's Open dialog -- it has a checkbox and a combo added at the bottom; they're placed on a borderless child dialog which is a child of the "Open" dialog.
Jugoslav
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
On this same subject, I've always been curious...
When the hook function is not called, the API dialog box has the History, Desktop, etc., buttons in a left frame.
When the hook is called, the buttons and left frame disappear.
Jugoslav, anyone, comments?
Greg
When the hook function is not called, the API dialog box has the History, Desktop, etc., buttons in a left frame.
When the hook is called, the buttons and left frame disappear.
Jugoslav, anyone, comments?
Greg
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I know about that problem; I've even read the answer once at compwin32... but I forgot it :-(. It has something to do with structure version & size. Let me see... yes, it's here. Does it work?
...It seems it does. If I put "12" into
OFN%lStructSize = SIZEOF(OFN)+12
to compensate for the missing pvReserved, dwReserved and FlagsEx, the places bar appears (of course, it's a no-no to leave it like that -- the structure needs rewriting). It seems that CVF translation of OPENFILENAME is outdated.
However, one should pay attention to cross-OS portability: on WinNT & older (GetVersionEx), OFN%lStructSize should be OPENFILENAME_SIZE_VERSION_400 (=SIZEOF(OFN) in CVF6.6B); otherwise, it should include 12 bytes above. Alternatively, one can try to invoke GetOpenFileName with "Full" size and retry with "smaller" size if GetLastError returns ERROR_INVALID_SIZE (or whatever it's spelled).
Jugoslav
...It seems it does. If I put "12" into
OFN%lStructSize = SIZEOF(OFN)+12
to compensate for the missing pvReserved, dwReserved and FlagsEx, the places bar appears (of course, it's a no-no to leave it like that -- the structure needs rewriting). It seems that CVF translation of OPENFILENAME is outdated.
However, one should pay attention to cross-OS portability: on WinNT & older (GetVersionEx), OFN%lStructSize should be OPENFILENAME_SIZE_VERSION_400 (=SIZEOF(OFN) in CVF6.6B); otherwise, it should include 12 bytes above. Alternatively, one can try to invoke GetOpenFileName with "Full" size and retry with "smaller" size if GetLastError returns ERROR_INVALID_SIZE (or whatever it's spelled).
Jugoslav
