|
thanks!
okay how do I do that?
|
|
|
|
|
I fell so dumb and inadequate today ... yesterday was such a good day!
I have a CButton derived button in a dialog ( a dialog app ) :
#include "MyButton.h"
CMyButton m_HelpButton;
and
...
void CTestColorControlDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_HELP_BUTTON, m_HelpButton);
}
...
My button is working nicelly, but I don't receive and message for WM_CREATE, or even the OnCreate virtual is not called.
I need to change the button size, from inside the class, at creation time; I don't want to have to manually create the button in the dialog's OnInitDialog just to do it.
Thank yo for helping a programmer in need!
Maximilien Lincourt
For success one must aquire one's self
|
|
|
|
|
You don't get the WM_CREATE message because windows creates a normal button first, and then subclasses it in the first call to the DoDataExchange method. When your class is attached to the button, the button has already been created.
You may be able to do want you want in the PreSubclassWindow() virtual method - this is called after the HWND is attached to your button, but before the window procedure has been replaced.
Dave
|
|
|
|
|
Controls created via a dialog template do not recieve the WM_CREATE message. Handle all control initialization in PreSubclassWindow() instead.
HTH
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote:
use PreSubclassWindow() instead
Thank You! Oh ! I Love You!!!
Max.
Maximilien Lincourt
For success one must aquire one's self
|
|
|
|
|
Maximilien wrote:
Oh ! I Love You!!!
hmmm, shall we meet for a drink later?;)
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
u devil u ;P
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
Hi, I have simple problem. I need get all users in my computer and for all users get special folder. Ist possible ? (no Common Folder etc)
Wiizi
|
|
|
|
|
Wizard_01 wrote:
I need get all users in my computer
NetLocalGroupGetMembers
NetLocalGroupEnum
Mazy
"And the carpet needs a haircut, and the spotlight looks like a prison break
And the telephone's out of cigarettes, and the balcony is on the make
And the piano has been drinking, the piano has been drinking...not me...not me-Tom Waits
|
|
|
|
|
|
Hello,
I am trying to use SHGetFolderPath in MFC app, however, I get error C2065: 'SHGetFolderPath' : undeclared identifier.
I have latest SDK, WinXP, and included the required header file shlobj.h.
if(SUCCEEDED(SHGetFolderPath(NULL, CSIDL_HISTORY, NULL, 0, lpPath)))<br />
{<br />
::SetCurrentDirectory(lpPath);
}
Why can't the linker find this shell function?
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
This is strange. According to my version of MSDN (October 2000), ShGetFolderPath is included in shfolder.h/shfolder.lib. However, my version of VC6 does not come with a shfolder.h. I also did a search for the function in any of the header files, and nothing.
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
don't know what version of MSDN you have but mine shows
Windows NT/2000: Requires Windows NT 4.0 or later.
Windows 95/98/Me: Requires Windows 95 or later.
Header: Declared in shlobj.h.
Import Library: shell32.lib.
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
I did a search for *.h file containing 'SHGetFolderPath' and I got it in ShlObj.h and ShFolder.h in Feb 2001 PSDK (last one I got for VC6) and also the same two files in the PSDK that came with VS.NET.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote:
I did a search for *.h file containing 'SHGetFolderPath'
I found the following in ShlObj.h
SHFOLDERAPI SHGetFolderPathA(HWND hwnd, int csidl, HANDLE hToken, DWORD dwFlags, LPSTR pszPath);<br />
SHFOLDERAPI SHGetFolderPathW(HWND hwnd, int csidl, HANDLE hToken, DWORD dwFlags, LPWSTR pszPath);<br />
#ifdef UNICODE<br />
#define SHGetFolderPath SHGetFolderPathW<br />
#else<br />
#define SHGetFolderPath SHGetFolderPathA<br />
#endif // !UNICODE
Sanity check:
I included the shlobj.h file, also, that file is in the SDK, and the SDK source files are in my included paths to search for while linking code.
it still doesn't work, am I missing something obvious?
TIA
R.Bischoff | C++
.NET, Kommst du mit?
|
|
|
|
|
The lines you quoted above are enclosed within:
#if (_WIN32_IE >= 0x500)
...
#endif // _WIN32_IE >= 0x500 Ensure you have _WIN32_IE properly defined.
HTH
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
If you are getting error C2065, that is a compiler error, not a linker error. You need to make sure the SDK include directories are listed first (Tools menu, Options, ...). You also probably need to define the WINVER variable in stdafx.h to be 0x500 or greater.
Software Zen: delete this;
|
|
|
|
|
I was wondering if one can still use direct video memory access in text mode to write characters to certain screen (screen now-a-days would just be a console window) positions.
In visual C++ 6, is there anything special you have to do to be able to use address 0xB8000000 in this way? I was thinking that the address should still be used for the console windows to maintain backwards compatibility with the old DOS applications, but maybe the console windows used by win32 console applications are quite different from the command line windows?
Thanks
|
|
|
|
|
The console windows are different in that they get the protection of the HAL, so direct video memory access is forbiden. Otherwise, you could access any hardware directly just by running through a console window and that would be a serious breach.
|
|
|
|
|
So is there a way to compile the program in visual C++ to be run within a true command window? I guess I'd need to be able to turn off the whole win32 as the target platform thing... I am not sure that is possible.
|
|
|
|
|
No. It's not a compiler issue or a 'true command line' issue. The operating system treats memory (all memory, including video) and I/O as protected resources. As such, the O/S reserves control over these resources in order to protect the system and other applications from ill-behaved applications.
Software Zen: delete this;
|
|
|
|
|
Sorry to be dense here, but doesn't that mean that old DOS programs would no longer run under windows? Hmm... I just got out 'Bad Blood' which is an old DOS game from 1990. It has reasonably fancy graphics (for the time). It ran fine on windows XP (much to my surprise) and my recollection from those days is that graphics pretty much always required direct video memory access. So there must be some special dispensation given by windows to these sorts of antiquainted programs... so presumably, if programs using old-style DMA don't work when compiled on visual C++ 6, the compiler must be adding some stuff to the executable indicated to the operating system that it shouldn't tolerate the DMA in the program.
|
|
|
|
|
Probably what's happening in this case is that XP has 'virtualized' the hardware sufficiently to make the DOS program think that it is accessing the hardware directly. In actuality, the processor intercepts the I/O instructions executed by the DOS virtual machine, and substitutes whatever actions it deems appropriate.
Windows XP goes much further along this path than any previous version, in order to smooth the way toward a common, Win32-based version of Windows. XP realizes that goal, partly through this virtualization and partly through the attrition of DOS applications.
My intent in my original response was mainly to discourage the author from pursuing this method in a new application. A much better approach would be to use the API mechanisms provided for the purpose, rather than relying on a 'band-aid' that may not be around in the next major release of the O/S.
Software Zen: delete this;
|
|
|
|
|
For old dos16 application windows starts Virtual Dos Mashine to emulate DOS environment. You can see it in task manager as ntvdm.exe process. Video memory of dos application can be found in this process memory at 0xB8000. (BTW the keyboard buffer is at 0x41A)
So, this is the way to control old dos application.
You can grab sceeen, and send keystrokes.
Dim.
|
|
|
|
|
Not quite understanding from MSDN what this is used for. Everything i spractically derived from CObject , so we should have IMPLEMENT_DYNAMIC in all code? What excatly does it do for us?
Generates the C++ code necessary for a dynamic CObject-derived class with run-time access to the class name and position within the hierarchy. Use the IMPLEMENT_DYNAMIC macro in a .CPP module, then link the resulting object code only once
Is it the "dynamic "that needs it? But we create CDialogs dynamically all the time and dont have this in them.
Sorry if I seem dazed but I am puzzled....
Appreciate your help,
ns
|
|
|
|