|
Are you using the same pointer in your dialog class as you are when you use the menu? Yes, I know it's a silly question, but I can't really think of any other reason why it wouldn't work.
The other thing you could try is to send a WM_COMMAND message corresponding to your menu item, so that all the window stuff is done in the same place. That would probably simplify things. I think this was mentioned before, but it's what I would do, so I'll mention it again 
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I am not using the same pointer....I don't know how to get the two classes to communicate with each other. Could you please show me how to get one pointer from one class to another one? I tried to do this, but was couldn't get the code to compile correctly.
How would I do the option you mention about the WM_COMMAND? I do not totally understand what you mean by this.
THANKS FOR YOUR HELP.
|
|
|
|
|
Jay Hova wrote:
How would I do the option you mention about the WM_COMMAND? I do not totally understand what you mean by this.
Say your menu item was ID_SHOWDIALOG (for example). You would send a message to your frame window exactly the same as what Windows does when a menu option is chosen.
AfxGetMainWnd()->PostMessage(WM_COMMAND, ID_SHOWDIALOG, NULL); Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I'm sorry for being so slow with this, but what does this exactly do. How will this solve my problem? Also where would i put this code. The code that I posted originally is the same code I use for both menu items...
Thanks again for your help and understanding
|
|
|
|
|
Ok. Basically, using that piece of code will simulate in software exactly what happens when the user selects a menu item. You would put this code where you handle the radio button being pressed, so that pressing the radio button behaves the same as selecting a menu item. This means that the code to actually display the dialog would only be in one place, and should solve your problem.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Many thanks Ryan. You just solved my problem that I have spent way too many hours on.
Worked like a charm.
|
|
|
|
|
You're welcome
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I feel sorry for my short and as I thought understandable answer. I didnot know, that you never coded before. So let me dig a little deeper with this answer.
In your main application class you should have a pointer to or an instance of class CMainCommand. This pointer or instance must be used by all calls to open the dialogs.
Have a look at the headerfile of your application class to find out, wheter the CMainCommand thing is private/protected or public.
In the application headerfile add a member function:
<br />
CMainCommand* GetCommandPointer(void);<br />
Assuming it is a pointer (lets call it pMainCommand) write in the applications cpp-file
<br />
CMainCommand* CWinApp::GetCommandPointer(void)<br />
{ return pMainCommand;}<br />
Of course you have to substitute CWinApp and pMainCommand with the names of the actual class name and variable name. If you do not use a pointer, but an instance of the class replace pMainCommand with &mainCommand;
In your OnOk handler write
<br />
m_pCommantOpt = DYNAMIC_DOWNCAST(CWinApp,AfxGetApp())->GetCommandPointer();<br />
Here too you have to substitute the CWinApp with the actual name of your application class. Also you have to include the applications header file into your cpp file. (But this should be done already by class wizard)
This line above does:
It retrieves a pointer to the application class instance, casts it to your application class and after the casting calls GetCommandPointer.
Then delete the line where you create an new instance of CMainCommand, bailing out, when the pointer is inavlid and tell the user that someting went wrong.
<br />
m_pCommantOpt = DYNAMIC_DOWNCAST(CWinApp,AfxGetApp())->GetCommandPointer();<br />
if( m_pCommandOpt != NULL )<br />
{ m_pCommandOpt = new CMainCommand(this);<br />
if( m_pCommandOpt->Create(IDD_MAIN_TAB_DIALOG) == TRUE )<br />
{ GetDlgItem(IDOK)->EnableWindow(FALSE);<br />
m_pCommandOpt->ShowWindow(SW_SHOW);<br />
}<br />
else<br />
{ m_pCommandOpt->SetActiveWindow(); <br />
}<br />
}<br />
else<br />
AfxMessagebox("Something went wrong");<br />
Regards
G.Steudtel
|
|
|
|
|
Thanks for all the help. I finally got it and it works just like you said it would. THANKS AGAIN!
|
|
|
|
|
Hello, I have a problem now. I want to disable cd rom autoplay function. Because i didn't want to autoplay in my program. I can't do it? May be it need modify register table. Can you help me? I wish you. Waiting online...
|
|
|
|
|
Look here[^]. Make sure you read the entire thread, especially the warnings by Tim Smith and John M. Drescher at the bottom.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi, Sir:
I saw your answer about disable CDROM autoplay function . and I think so that It is a very bad idea to change people's registry. And I have sawn the "Enable and Disable AutoPlay" in MSDN. I do it that:
UINT g_uQueryCancelAutoPlay = 0;
BOOL DialogProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg) {
...
default:
if (!g_uQueryCancelAutoPlay)
{
g_uQueryCancelAutoPlay = RegisterWindowMessage(TEXT("QueryCancelAutoPlay"));
}
if (uMsg == g_uQueryCancelAutoPlay)
{
SetWindowLong(hDlg, DWL_MSGRESULT, TRUE);
return 1;
}
}
}
but I can't success. Can you tell me How to do it? I wish to get your reply? Thanks
|
|
|
|
|
Are you using that exact code? You'll need to ues hWnd instead on hDlg in the call to SetWindowLong() otherwise it won't compile.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi, Sir:
I do it like that. But I can't success too. It seems that it can't get the message. And I use the code in PretranslateMessage(), but it can't work, too. I don't know why it is. My program is a dialob-base program. Have you a example to do that? if you have, I wish to get it from you? Thanks your reply. You are welcome.
|
|
|
|
|
michaelwan007 wrote:
Have you a example to do that?
No, sorry 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi all,
I want to set screensaver..I have to download a screensaver from a server and set it to the default screensaver...can anyone help me out here..I hope this is possible..Please help me out...Any help and pointers are highly appreciated..Thanks a lot in advance..
Himanshu
|
|
|
|
|
The user's current screensaver is stored in the registry: HKEY_CURRENT_USER\Control Panel\Desktop\SCRNSAVE.EXE key. Just set the path to the screensaver executable there.
Hope this helps,
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
hi,
thanks a lot..can u give me some code which queries the value of registry or overwrites it..any functions will also do..thanks a lot again..I appreciate ur help..
Himanshu
|
|
|
|
|
RegOpenKeyEx()
RegCreateKeyEx()
RegQueryValueEx()
RegSetValueEx()
etc...
|
|
|
|
|
Hi there...
I'm writing a app in VC++ that needs a database, I'm currently using this ODBC recordsetclass (Using MFC)
I thought that working with recordsets will make the fastest way to eg insert 100.000 entries into the database as quick as possible...
I've tested with a simple MS Access database and it took over 6 minutes to insert 100.000 dummy entries (1 text field, with 255 chars)
Since it takes some time to test'em all, I would ask if anybody know which protocol is the fastes? ODBC/ADO/OLE ????
===================
Lars [Large] Werner
lars@werner.no
===================
|
|
|
|
|
ODBC is generally a bit slower than OLE DB, because there are more layers involved - you talk to the ODBC manager, which talks to a driver, whereas with OLE DB, your program talks directly to the provider.
However, your experience may be different, depending on the driver or provider. One supplier's OLE DB provider might be less well optimised than their ODBC driver.
Using the native OLE DB provider will always be quicker than using MSDASQL, which is an OLE DB provider that wraps the ODBC manager. This allows connections to work - it says nothing about performance.
In this particular case, I suspect that your problem is actually per-statement overhead. If you can perform a batch update or insert, that would probably be better. I'm not sure how to go about this with ODBC - it's structured around executing SQL statements, so you probably need to have it execute a big batch of INSERT statements all chained together as a single logical statement.
For OLE DB, you ask for the IRowsetUpdate interface and use the InsertRow method to insert a new row. Once all rows are inserted, you call the Update method to update a complete batch of rows.
From C++, I would personally avoid ADO. You spend a lot of time working around the VBisms of the interface rather than being productive, IMO.
|
|
|
|
|
Replace CRecordset by CDaoRecordset and CDatabase with CDaoDatabase when working on MS ACCESS (in other words: use DAO for MS ACCESS). It very much faster.
Keep away from ADO. MFC does not yet contain wrapper classes and to my experience it contains some bugs which are hard to overcome with VC.
MS
|
|
|
|
|
Manfred Staiger wrote:
Keep away from ADO. MFC does not yet contain wrapper classes and to my experience it contains some bugs which are hard to overcome with VC.
 I switched from DAO to ADO to get around the multitasking bugs and after using ADO for over 2 years I have yet to find a bug...
John
|
|
|
|
|
well, if you need performance, just do ONE thing... DONT USE ACCESS!!!!!!!! Doh!
Of course the protocol matters, but the most important thing is the database. MySQL is probably the fastest, but its also very limited in terms of SQL advanced features. SQL server is vgood and only gets slow when you use it through MSDE.
Also the key feature to a fast DB acess is a good DB design and avoiding complex queries. If you need complex results, make simple queries and then work it out in the client side. C++ is a very powerfull and fast language, so y(?) overloading the DB server with complex queries, when you can produce faster results using a bit of code when handling results?
In terms of protocol, there are a lot more protocols than those u mentioned. Most of them are only avaiable to a specific DB (Oracle, PostGreSQL, MySQL) but their performance is great cause they are optimized for that DB. ODBC is just a wrapper.
|
|
|
|
|
The idea is to use the lame MS Access at the start, and then later upgrade the system to SQL... I've found the ODBC driver pretty easy to change between them!
At work we use ASP and the recordsets there are pretty quick against the SQL, is that the same as ADO, or is that a direct OLE DB functions?
I also making a hunt for a good grid control... The MS Grid pretty much sux, as I see it... Does anybody have any other controlls that are good for the purpose to show much data?!
What advice would you give me , for selecting the the fastes and best protocol that is easy to use for MFC?! I have tested OLE DB Express or something like that, and I've tested the ADO, and ODBC... The ADO seems pretty quick on the Access for me, is it also quick in the SQL?!
===================
Lars [Large] Werner
lars@werner.no
===================
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
