|
Excellent link, Josh - Thanks!
It looks like, if I'm going to pursue this, I'll need to install the DDK and learn to use it. Oh well, nothing easy is worth having...
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
What OS do you want compatiblity with? You can use SPTI in NT and use ASPI in 9x
SPTI
Have a look for opening CDRom drives using CreateFile, you can read sectors other than data using DeviceIoControl and IOCTL_CDROM_RAW_READ
ASPI
If you using ASPI then you can use many of the read commands defined in the SCSI 3 specification. READ_CD being your best bet.
Regards,
Ceri
|
|
|
|
|
Sounds promising - thanks!
Will Build Nuclear Missile For Food - No Target Too Small
|
|
|
|
|
I'm writing an app that when a certain event is received it brings itself forward to the top window on the z-order. However I cannot get this to happen on a win xp pro environment.
I tried this example that I found but this does not work
AttachThreadInput(<br />
GetWindowThreadProcessId(<br />
::GetForegroundWindow(),NULL),<br />
GetCurrentThreadId(),TRUE);<br />
<br />
SetForegroundWindow();<br />
SetFocus();
<br />
AttachThreadInput(<br />
GetWindowThreadProcessId(<br />
::GetForegroundWindow(),NULL),<br />
GetCurrentThreadId(),FALSE);
I've also tried this:
<br />
::AttachThreadInput(GetWindowThreadProcessId(hWnd, NULL) ,GetCurrentThreadId(), TRUE);<br />
::DefWindowProc(hWnd, WM_SYSCOMMAND, SC_RESTORE, NULL);<br />
::SetForegroundWindow(hWnd);<br />
::SetFocus(hWnd);<br />
::ShowWindow(hWnd, SW_SHOWNORMAL);<br />
::AttachThreadInput(GetWindowThreadProcessId(hWnd, NULL) ,GetCurrentThreadId(), FALSE);<br />
Still does not being itself forward.
Does anyone have any suggestions?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
You could try setting it as the topmost window
::SetWindowPos(hWnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE);
Though you will have to revoke this if you want other windows to move over it afterwards.
Ant.
|
|
|
|
|
OR replace HWND_TOPMOST with HWDTOP to move to the top without making it permanent.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
So, you're actually trying to call SetForegroundWindow, but the lock feature is working.
Good. It's supposed to. The user doesn't want to be interrupted by your program. If you really must, it is possible to change the lockout behaviour using SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT), but you can only do this if you're already the foreground window or a call to SetForegroundWindow would succeed.
Stability. What an interesting concept. -- Chris Maunder
|
|
|
|
|
I do not believe that this is the case. This is why. Currently I'm writing this code in a dll that a COBOL application is calling (so that it can pop itself to the top of the z-order). This same code is in a test .exe and it works great. I type in the title of the window I want to come forward and it comes forward.
This same code works great on Winnt 4.0, w2k, but I cannot get it to work on XP. So what is the difference between 2000 and XP?
Thanks for the help
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
I have been using an application-defined comparison function for sorting CListCtrl in Report format. The item string is obtained by searching the list for a match on the item data (see below). This works fine if there are subitems, however with NO subitems the ASSERT fires. If the list control is redrawn during the sort, the row with lParam1 is missing - replaced by a duplicate of another row.
Any ideas?
Many thanks.
int CALLBACK CSortListCtl::CompareItems( LPARAM lParam1, LPARAM lParam2, LPARAM lParamData )<br />
{<br />
....<br />
<br />
LVFINDINFO findInfo;<br />
findInfo.flags = LVFI_PARAM;<br />
findInfo.lParam = lParam1;<br />
int index1 = pListCtrl->FindItem( &findInfo );<br />
ASSERT( index1 > -1 );<br />
CString text1 = pListCtrl->GetItemText( index1, subItem );<br />
<br />
....<br />
}
|
|
|
|
|
This is the incorrect usage of the comparison function. When you add items to a list control using InsertItem(), you should follow that with a call to SetItemData(). Then in the comparison function, the values passed in as lParam1 and lParam2 are used as pointers to the item data. Here's a brief example:
CString *pName = new CString("Mason");
int nItem = m_listctrl.InsertItem(0, *pName);
pName = new CString("Dixon");
nItem = m_listctrl.InsertItem(1, *pName);
pName = new CString("Woodrow");
nItem = m_listctrl.InsertItem(2, *pName);
...
int CompareFunc( LPARAM lParam1, LPARAM lParam2, LPARAM lParamData )
{
CString *str1 = (CString *) lParam1,
*str2 = (CString *) lParam2;
return str1->CompareNoCase(*str2);
}
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
If you use the sequence
pName = new CString("Dixon");<br />
nItem = m_listctrl.InsertItem(1, *pName);<br />
m_listctrl.SetItemData(1, pName);
repetitively, all the string data in the list is duplicated in the CString objects. You will also need to add extra code to delete all the CStrings before the control is destroyed (or possibly subclass and override OnDestroy()). Hence the attraction of using FindItem() albeit at the cost of lots of searches.
The point that I wanted to make is that FindItem() doesn't appear to work during sorting if you have no subitems - unless I've got my code wrong.
Of course, we would not be having this discussion if instead of supplying lParam's, LVITEM's were passed instead with a predefined mask.
|
|
|
|
|
Background:
My application restricts the capabilities of users without administrator privileges and provides an "administrator override" capability that allows an administrator to supply credentials so that restricted operations may be performed without terminating the app. This capability is designed to work on Windows 2000 and XP. The app requests user credentials with a logon dialog box. It then validates them and impersonates the user with administrator privileges using code modified from the samples supplied with Microsoft KB article Q180548. This mechanism works correctly on Windows 2000 SP3.
Problem:
After installing SP4 or some other recent Hotfix, the administrator override capability no longer works. After the app impersonates a user with administrator privileges, it can no longer open a registry key in HKEY_CURRENT_USER for reading and writing. The call:
RegOpenKeyEx (HKEY_CURRENT_USER, pszKeyName, 0,
KEY_READ|KEY_WRITE, &hRegKey);
fails, returning a value of 1346 (0x542), listed in Winerror.h as ERROR_BAD_IMPERSONATION_LEVEL.
What must I change in the app to fix this problem?
|
|
|
|
|
ICantChangeMyAcct wrote:
After the app impersonates a user with administrator privileges...
Are you sure this part still works? The 0x542 error has two meanings: either a required impersonation level was not provided, or the provided impersonation level is invalid.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I'm not sure what "works" means. The Q180548 code uses secur32.dll functions to generate a "client context" and a "server context", then calls the function ImpersonateSecurityContext() with the *server's* context handle (!?!) This function returns SEC_E_OK, indicating that the impersonation "worked". My app doesn't use the context handle in system calls or do anything that requires administrator privileges.
|
|
|
|
|
Hi.
Do anyone know how I make my programs to only open one time and not multiplie times? Exampel when my program is open and I start it again then the already open program shall show up and not open it again. Just like Windows Media player.
|
|
|
|
|
See here and here.
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
I have the following code that I am executing:
DWORD last_err;
WNDCLASS wc;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) WindowProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.lpszMenuName = "MainMenu";
wc.lpszClassName = "MainWindowClass";
if (!RegisterClass(&wc))
{
last_err = GetLastError();
}
The RegisterClass call fails and when I run the code in debug and last_err gets set it has a value of 0. I'm expecting it to have a value that designates just what the error was. I got this code fom the following example:
int APIENTRY WinMain(
HINSTANCE hinstance,
HINSTANCE hinstPrev,
LPSTR lpCmdLine,
int nCmdShow)
{
WNDCLASS wc;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) MainWndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hinstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = "MainMenu";
wc.lpszClassName = "MainWindowClass";
if (!RegisterClass(&wc))
return FALSE;
}
This comes from the help index under "Using Window Procedures".
Robert
|
|
|
|
|
Do you get the same results when using RegisterClassEx()?
"The pointy end goes in the other man." - Antonio Banderas (Zorro, 1998)
|
|
|
|
|
|
Looks ok to me. Check that your hInstance param is correct and also your WindowProc and lpszMenuName.
----
lpszMenuName
Pointer to a null-terminated character string that specifies the resource name of the class menu, as the name appears in the resource file. If you use an integer to identify the menu, use the MAKEINTRESOURCE macro. If this member is NULL, windows belonging to this class have no default menu.
----
I don't know why GetLastError() returns 0.
If you are using MFC you may want to look at AfxRegisterWndClass() or AfxRegisterClass().
Neville Franks, Author of ED for Windows www.getsoft.com and coming soon: Surfulater www.surfulater.com
|
|
|
|
|
Neville,
My hInstance param comes right from my main window creation, just like the example:
int PASCAL WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR szCmdLine, int nShow)
{
hInstance = hInst;
I changed the name of my WindowProc routine to MyWindowProc just so that it wasn't the default anymore. That routine is at the top of the module that contains the code in question:
LRESULT CALLBACK MyWindowProc(HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
)
{
int dummy_var;
dummy_var = 1;
return 1;
}
My lpszMenuName is NULL. My intent is to create a window that is invisible later on by calling CreateWindow for the purpose of processing messages only. The reason that I am calling RegisterClass is because I assumed that I needed to do this prior to getting the CreateWindow to work. BTW, that is also returning a 0 when it fails and I check GetLastError. Very strange.
The help message that describes the kind of window that I want to create is here:
From CreateWindow...
hWndParent
[in] Handle to the parent or owner window of the window being created. To create a child window or an owned window, supply a valid window handle. This parameter is optional for pop-up windows.
Windows 2000/XP: To create a message-only window, supply HWND_MESSAGE or a handle to an existing message-only window.
Message-Only Windows
A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.
To create a message-only window, specify the HWND_MESSAGE constant or a handle to an existing message-only window in the hWndParent parameter of the CreateWindowEx function. You can also change an existing window to a message-only window by specifying HWND_MESSAGE in the hWndNewParent parameter of the SetParent function.
To find message-only windows, specify HWND_MESSAGE in the hwndParent parameter of the FindWindowEx function. In addition, FindWindowEx searches message-only windows as well as top-level windows if both the hwndParent and hwndChildAfter parameters are NULL.
As to the last reference to MFC, I am not using it.
Robert
|
|
|
|
|
In your code hbrBackground member is not initialized. It should be either NULL or valid HBRUSH.
Maksim Lepikhin
www.softforpros.com
|
|
|
|
|
This was the problem. I had the following code commented out:
I believe I did this because it didn't compile. I had to add a cast to it:
wc.hbrBackground = (HBRUSH)GetStockObject(WHITE_BRUSH);
The code was originally from some sample code. Figures it wouldn't compile...
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) MainWndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hinstance;
wc.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wc.hCursor = LoadCursor(NULL, IDC_ARROW);
wc.hbrBackground = GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = "MainMenu";
wc.lpszClassName = "MainWindowClass";
Thanks Maksim,
Robert
|
|
|
|
|
Whats the simplist way to encrypt/decrypt a user's plaintext password? I'd like to give them a "Save your password" checkbox so that they won't need to type it again. Saving it as plain text would be a (possibly minor) security flaw, and using a hash wouldn't work because I wouldn't be able to decrypt it before passing it on to the authentication module.
Basically, what I'm getting at is: Are there any "standard" encryption methods for use on plain text passwords?
(NOTE: The encryption doesn't have to be very strong, just something that gives the text a sufficient "jumbling up" would suffice.)
Thanks! 
--
Edward Livingston
(aka ExtraLean)
--
"I still maintain that seeing a nipple is far less disturbing than seeing someone get their brains blown out." -- Chris Maunder
|
|
|
|
|
Use MD5 encryption. A lot of free C++ libraries provides it, for example here.
Tip: you shouldn't decrypt the password . Instead, in the authentication module, retrieve a password from user, encrypt it by MD5 and compare it with the saved (encrypted) password.
Robert-Antonio
"CRAY is the only computer, which runs an endless loop in just 4 hours"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
