|
CShellLink::Initialize() calls CoCreateInstance(). Yet, it fails!
Maybe there's something wrong with my Win2000???
--BlackSmith--
"With the help of all mighty", 2001, Me.
|
|
|
|
|
you have put:
if (!AfxOleInit()){
AfxMessageBox(_T("OLE Init Failed ... aborting!"));
return FALSE;
}
in ur InitInstance() right?
"... and so i said to him ... if it don't dance (or code) and you can't eat it either f**k it or throw it away"
sonork: 100.18128 8028finder.com
|
|
|
|
|
I can get a cmnd* to my toolbar but I need a cwnd* for a button on the toolbar. How can i do this? Do the buttons not have a cwnd*?
Thanks
|
|
|
|
|
No, the individual buttons on a toolbar are not windows. You can verify this with Spy++
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I have a modal dlg spawned by an MDI view class. THere is a data variable array called m_Fld[10] in my doc class. I want to transmit this info to the dlg launched from the view class. After I get user input in the dlg corresponding to processing this array, I want to store it in another doc variable.
Here is my thought. If theres something simpler I'd like to know. This sounds a bit complicated.
First I make a class CMOdalDlg which has a member array m_DlgFld[10], a MyDoc* m_pDlgDoc, and MyDoc.h include. It also has a function called
CModalDlg::SetDocPointer( MyDoc* pdoc)
{
m_pDlgDoc =pDoc;
}
Then after I do (in the view)
CModalDlg myModalDlg;
for (int i = 0, i < 10; i++)
{
myModalDlg.m_DlgFld[i] = pDoc->m_Fld[i];
}
myModalDlg.SetDocPointer(pDoc);
myModalDlg.DoModal();
Then in the OnInitDialog of myModalDlg I can process this array (it populates a listcontrol in the dialog), get user input from the form, store it in m_pDlgDoc->m_somemember, and say OK to return from the DoModal().
I hope this isnt too confusing. Is this the way to go about it or is there a simpler mechanism I'm unaware of?
Thanks,
ns
A pre-translate message problem -I prevent the dismissal of the dlg due to Enter key with a pretranslate event. But this makes the dlg unresponsive to all Enter presses. So after the user enters data into a CEdit object called m_edit, what action should I take to put this entered info into my doc variable? Do they have to press an 'Done' button which will do the data copy? If I want an Enter to copy the user input info into the doc var, how is this accomplished (assuming I can respond to Enter?) There is no function that runs like the BN_clicked of 'Done' button when you press enter, right?
Anyways I cant respond to enter anyways so I'll have to have a'Done' button, though an 'Enter' would be cooler.
Any thoughts on this?
Hope my issues are clear...
Thanks for any ideas,
ns
|
|
|
|
|
If you're passing a pointer to the doc to the dialog, you don't need to populate the dialog's m_DlgFld member. In fact, you don't even need this member. In the dialog's OnInitDialog(), simply access the doc's member and load the list control.
In general it's a good idea to not duplicate data. It makes verifying program correctness difficult.
|
|
|
|
|
nss wrote:
I prevent the dismissal of the dlg due to Enter key
I suggest not using pre-translation because (as in your case) it can be overkill. Instead simply override the dialog's OnOK() handler to return without calling CDialog::OnOK(). Then, replace the IDOK button with a button of a different id, eg: ID_EXIT. In it's handler, call CDialog::OnOK().
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Okay. If I do what you say and can have Enter recognised, how do I transfer the contents of my CEdit into the doc var when the user enters the input and presses enter? Theres no CEdit function that runs when you press Enter while in it, correct? So a BN_CLICK of a "Done" button is what I'm thinking. Yet we know that apps exist where you can put data into CEdit, press Enter and information gets transmitted. What is the function that runs when you are done entering data in the CEdit and press Enter?
Questions, questions! Thanks for reading through my design dilemma, and indeed I was duplicating data as I now see. Good thing I havent started yet!! Thanks so much for your clarity!
Theres an _ASSERTE that I'm going to check out. tells you what went wrong it seems (or maybe ASSERT does that anyways)
|
|
|
|
|
nss wrote:
how do I transfer the contents of my CEdit into the doc var when the user enters the input and presses enter
Just add this to your OnDone() handler:
ASSERT (m_pDoc != NULL);
GetDlgItemText (IDC_MyEdit, m_pDoc->m_someString);
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Heres what you are saying: Let the onOk handler be blank (no base onOk call).
Delete the OK button?
Put in new button and different ID - call base OnOk in it. So - should I delete the Ok button or invisible it or rename its ID to ID_EXIT?
|
|
|
|
|
just rename the caption of the button to 'Done' for example and change its id to IDC_DONE for example ... add a click event handler and call the CDialog::OnOK(); at the end of the processing u want done there
to exchange all the data vars u can use UpdateData(TRUE) to get all the values the user entered (some ppl prefer not to use the DataExchange stuff and get the values out manually)
"... and so i said to him ... if it don't dance (or code) and you can't eat it either f**k it or throw it away"
sonork: 100.18128 8028finder.com
|
|
|
|
|
|
to exchange all the data vars u can use UpdateData(TRUE) to get all the values the user entered
When do I call UpdateData? after the user finishes entering data into the CEdit what should he do? The UI has to trigger some function where Updatae data gets called right? I'm confused. I was hoping to have the user put in the data, press enter and somehow the doc var to get updated magicallly. But which function is going to run where I can call UpdataDAte when Enter is pressed. Do uou see my dilemma?
Thanks for helping...
ns
|
|
|
|
|
Delete the IDOK button.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Hi!
Is there a way to include files into a project as a resource that still can be read using fopen() ?
Currently my app is reading some data from an external file that is in my app's directory. But I do not want the user to change this file, so I want to include it as a resource into my EXE/DLL. Is this possible?
If it is possible, how can I then read it with the standard I/O functions?
thanks in advance
modified 12-Sep-18 21:01pm.
|
|
|
|
|
the easiest way is to open/lock the resource then dump the contents to a temporary file.
-c
Conservative:
One who admires radicals centuries after they're dead.
-- Leo C. Rosten
|
|
|
|
|
thanks for your reply!
I'm aksing myself whether this is possible:
Currently my app reads a whole file into a variable called "cache"
fread(cache, sizeof(char), buf.st_size, db);
I thought it would be nice to put the database (db) into my exe as a resource, so that I directly could set the buffer like that:
cache = (unsigned char*)rc_dat;
rc_dat is the content of the resource I'v got from the LockResource call.
But I think it doesn't work as expected
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Don't care about it anymore. Everything works fine 
modified 12-Sep-18 21:01pm.
|
|
|
|
|
My application makes extensive use of the GDI resources. I use them to draw text in the view using specific font information etc... Anyway, the application terminates due to the fact that it eats up all of the system's available GDI resources. I'm trying to eliminate this issue but have had no luck. Even when using the DeleteObject() function, the GDI resources are never freed. Does anyone know how to free the GDI resources successfully?
|
|
|
|
|
ooooooooooooh...
CPen pen;
pen.CreatePen(PS_SOLID,1,RGB(255,0,0);
dc.SelectObject(&pen);
pen.DeleteObject(&pen);
problem...
SelectObject selects your pen and give you the previous pen. This must be selected back in the dc before pen is deleted.
so...
CPen* pPrevPen dc.SelectObject(&pen);
... do some drawing
dc.SelectObject(pPrevPen)
pen.DeleteObject(&pen);
and this goes for every GDI object you select into the DC, fonts, brush, etc.
Normski. - the next bit of code is self modifying ... jmp 0xCODE
|
|
|
|
|
I'm selecting the old pen back into the DC and deleting the object, but I'm not getting the resources to free up on my system. I've tried using the CAutoPen class that I found on this site to initialize, select, and delete the Pen object from the DC. I've also tried using the CPen class and just creating a pen, selecting it into the DC, using it, selecting the old pen back into the DC, and deleting the object. Neither method has worked. I'm not sure what I'm doing wrong to hold these GDI resources.
|
|
|
|
|
Hi.
I would like to implement a context menu inside a dialog box. I created a "clear" menu (no caption) using Resource Editor. Note that I create an entirely new menu item like IDR_MAINFRAME (mine is IRD_CONTEXTMENU1. Inside the dialog box, I added a message for right-click. Here is what the code looks like.
-----
CPoint mPointCurrent;
::GetCursorPos(&mPointCurrent);
CMenu mPopupMenu;
mPopupMenu.LoadMenu(IRD_CONTEXTMENU1);
// Program crashes at this point.
CMenu *pContextMenu = mPopupMenu.GetSubMenu(0);
pContextMenu->TrackPopupMenu(TPM_LEFTALIGN | TPM_LEFTBUTTON | TPM_RIGHTBUTTON | TPM_RETURNCMD | TPM_NONOTIFY,
mPointCurrent.x, mPointCurrent.y, GetActiveWindow(), NULL);
-----
The code above does not work. The program crashes when I right-click inside the dialog box. Is the code above for a view class only? Is there a different and corrent way to implement a context menu inside a dialog box?
Thanks,
Kuphryn
|
|
|
|
|
I thing your problem is that you are passing argument &mPointCurrent in client coordinates. You need to implement function ClientToScreen()and converse it into screen coordinates.
ClientToScreen(&mPointCurrent);//after mPopupMenu.LoadMenu
|
|
|
|
|
No, ::GetCursorPos() returns screen coordinates, and that's what TrackPopupMenu() expects. I do wonder if maybe having both TPM_LEFTBUTTON and TPM_RIGHTBUTTON set could be causing problems though...
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
|
I don't know.
But, you can rule out a couple of things right off: put in an ASSERT() for pContextMenu, and for GetActiveWindow(). If either one triggers, there's your problem:
CMenu *pContextMenu = mPopupMenu.GetSubMenu(0);
ASSERT(NULL != pContextMenu);
ASSERT(NULL != GetActiveWindow());
---
Shog9
If I could sleep forever, I could forget about everything...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
