|
|
tried this, it positions the window off screen
|
|
|
|
|
Does MoveWindow() produce the same result? I'm not sure if either support CW_USEDEFAULT.
You might want to explain this requirement further. Perhaps there's a better alternative.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hi,
I am trying to use the Seek method in an ADO recordset object. It works fine if the index is only one field. For an index with multple fields, say two strings, I cannot seem to make it work properly.
MSDN says that the first argument is a Variant array.
example code:
_variant_t varKeys[2];
varKeys[0] = "value1";
varKeys[1] = "value2";
m_pRecordset->Seek( varKeys, adSeekFirstEQ );
What happens is that only the first value seems to taken into account.
Any ideas ?
note: I am using an MDB (Access) database. Opening using Jet4 conenct string.
thanks,
Louis.
|
|
|
|
|
ldaoust wrote:
MSDN says that the first argument is a Variant array.
It seems like rather than an array of variants, what you need is a single variant containing an array of values.
Check this article[^].
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Great, thanks. Got it to work based on that article.
thanks again.
--
Louis.
|
|
|
|
|
If I have a class made in my MFC application I am making I get a very fun bug. This also happens if i call delete on an object I have allocated and of course even though a memory leak when a homemade class goes out of scope.
So tell me how can i make a class or use delete on objects or eve my own classes? Here are my linker errors:
Prog error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in libcpmtd.lib(newop.obj)
Prog error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
Prog fatal error LNK1169: one or more multiply defined symbols found
Isn't that great? So i narrowed it down to creating a class and it going out of scope as well as the call of a destructor or even just deleting a simple character array.
|
|
|
|
|
I suspect the problem is your sytnax when you call new and delete. It obviously thinks you're trying to define these operators, or at least that they are multiply defined elsewhere.
Try creating a brand new project, and adding a char * with new and delete in your main. If that doesn't work, your compiler setup is screwed. OTherwise, your project is somehow screwed.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
how can I get the registered window class name from an HWND?
No MFC allowed.
Thanks in advance!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.santacruznetworks.com">Santa Cruz Networks</A>
|
|
|
|
|
GetClassName
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Hey there,
I have an application which has a "ThunderRT6UserControlDC". There are various control within this container such as
1. A drop down box
2. Label box
3. Gifs
4. a List View
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
I need to get the handle to the Label box (2) to retrieve its text. I'm trying to access this from a different program so I have to use handles and cannot use properties withing my application.
Any suggestions!!
Abhishek
|
|
|
|
|
Abhishek Karnik wrote:
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
Are they obscured by some other control like a groupbox?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hey David,
I'm not sure ..... the ThunderRT6UserControlDC is a child of ThunderRT6PictureBoxDC which contains a number of ThunderRT6UserControlDC's. However I don't think its obscured. If it were it would have shown up in Spy++ ( is assume).
regards
Abhishek
|
|
|
|
|
Abhishek Karnik wrote:
Hey there,
I have an application which has a "ThunderRT6UserControlDC". There are various control within this container such as
1. A drop down box
2. Label box
3. Gifs
4. a List View
For some reason 1 and 2 are not visible as having handles when viewed from Spy++.
One possible reason for those controls not appearing in Spy++ is that they might not be separate windows. The drawing and behavior of those controls might be implemented directly inside ThunderRT6UserControlDC.
Is that a VB app? I seem to remember reading somewhere that VB implement some basic controls entirely by its own without creating actual Win32 windows for them. That would explain what you are seeing (and what not) in Spy++...
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
hey Jose,
If they are implemented directly inside ThunderRT6UserControlDC, do you think there is some way of extracting the text.....using a Gettext or something.......because I am not sure if that would work since the there seem to be subcomponents with different structures (like the drop down compared to a text box)
Jose Lamas Rios wrote:
Is that a VB app?
Yes the application that I am targetting is a VB application...I'm sriting my code in VC.
|
|
|
|
|
Abhishek Karnik wrote:
If they are implemented directly inside ThunderRT6UserControlDC, do you think there is some way of extracting the text.....using a Gettext or something
No, if that is the case, I don't think there is a way to get the text.
But maybe you can find something googling for ThunderRT6UserControlDC or asking in a VB forum...
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Hey all
Ive created a API modeless dialog inside of a DLL, and is created whenever the calling program calls the appropriate exported function. In a past thread that i posted, this dialog would cause the application to lock up with the not responding dialog. Thanks to someones tip to use DefWindowProc() I can now get the dialog to work (pops up, and close button properly closes when clicked), only it appears to not be responding to move messages (the message called when i would like to drag the dialog around on the screen).
From DLLMain:
<br />
hDLL = hinstDLL;<br />
The exported function that starts the dialog:
<br />
<br />
<br />
int __stdcall WINAPI x(HWND mWnd, HWND aWnd, char *data, char *params, BOOL show, BOOL nopause){<br />
<br />
MSG msg;<br />
<br />
hDlg = CreateDialog(hDLL, MAKEINTRESOURCE(IDD_DIALOG1), mWnd, (DLGPROC)DlgCallBack);<br />
<br />
ShowWindow(hDlg,SW_SHOW);<br />
<br />
while (GetMessage(&msg, NULL, 0,0)) {<br />
TranslateMessage(&msg);<br />
DispatchMessage(&msg);<br />
}<br />
}<br />
The DLGPROC:
<br />
LRESULT CALLBACK x(HWND hwnd,UINT uMsg,WPARAM wParam,LPARAM lParam){<br />
switch (uMsg) <br />
{ <br />
case WM_COMMAND:<br />
<br />
switch(wParam){<br />
case IDOK:<br />
DestroyWindow(hDlg);<br />
return TRUE;<br />
}<br />
<br />
break;<br />
<br />
case WM_DESTROY: <br />
DestroyWindow(hDlg);<br />
PostQuitMessage(0);<br />
return TRUE;<br />
}<br />
<br />
return DefWindowProc(hwnd, uMsg, wParam, lParam);<br />
}<br />
|
|
|
|
|
KnaveR wrote:
while (GetMessage(&msg, NULL, 0,0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Shouldn't this be:
while (GetMessage(&msg, NULL, 0,0))
{
if (! IsWindow(hDlg) || ! IsDialogMessage(hDlg, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thnx for this suggestion, I was wondering how GetMessage could could possibly be knowing that the msg was for my dialog... this answered that. However, I am still unable to move the dialog, any suggestions?
|
|
|
|
|
Maybe you should try patching up your switch for WM_COMMAND, considering this note in MSDN:
The WM_COMMAND message is sent when the user selects a command item from a menu, when a control sends a notification message to its parent window, or when an accelerator keystroke is translated.
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
You completely switched on wParam instead of breaking out the hiword and loword 
switch( LOWORD(wParam) ){<br />
case IDOK:<br />
DestroyWindow(hDlg);<br />
return TRUE;<br />
}
|
|
|
|
|
Thnx for pointing that out, but it seems something else might be amiss. I just tried putting my "return DefWindowProc(hwnd, uMsg, wParam, lParam);" statement at the top so that all messages would be handled by the default window proc, thinking that this would allow my dialog to perform basic dragable behavior, but it is still not budging.
One other thing i noticed is that if i use my hDlg, which i get from CreateDialog(), inside the DefWindowProc an exception is thrown. Am I wrong in thinking that this should work, as hDlg works with calls to DestroyWindow?
I also would like to thank you all for your help, I have spent many days trying to track down what I am doing wrong.
|
|
|
|
|
KnaveR wrote:
return DefWindowProc(hwnd, uMsg, wParam, lParam);
Shouldn't this be return DefDlgProc(hwnd, uMsg, wParam, lParam); instead?
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
DefDlgProc will cause infinite recursion if i use it 
|
|
|
|
|
Given this note in MSDN in relation to possessing a DialogProc:
You should use the dialog box procedure only if you use the dialog box class for the dialog box. This is the default class and is used when no explicit class is specified in the dialog box template. Although the dialog box procedure is similar to a window procedure, it must not call the DefWindowProc function to process unwanted messages. Unwanted messages are processed internally by the dialog box window procedure.
Have you just tried returning FALSE instead of other processing, as per this note:
Typically, the dialog box procedure should return TRUE if it processed the message, and FALSE if it did not. If the dialog box procedure returns FALSE, the dialog manager performs the default dialog operation in response to the message.
Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc.
Also, there is this note:
If the dialog box procedure processes a message that requires a specific return value, the dialog box procedure should set the desired return value by calling SetWindowLong(hwndDlg, DWL_MSGRESULT, lResult) immediately before returning TRUE. Note that you must call SetWindowLong immediately before returning TRUE; doing so earlier may result in the DWL_MSGRESULT value being overwritten by a nested dialog box message.
|
|
|
|
|
You are Da Man!!! A million thnx!!!
Have you just tried returning FALSE instead of other processing, as per this note... Maybe with the improved handler (using the IsDialogMessage) you don't need to call DefWindowProc.
Originally I was returning FALSE, but was not using IsDialogMessage. Hope that this helps someone in the future.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
