|
You could just give it a shot and see if it's what you want. (The traditional approach.  )
An additional idea is to make the control a list view in report mode. Don't insert anything into the first column and make it of zero width. The second column can hold your list items. This arrangement could make it so that the user can't make the control look as though something is selected.
Another idea is to simply use a read-only multi-line edit control.
John
|
|
|
|
|
Hi guys, This seems like it should be really easy, but... I have this ActiveX control started with the MFC 7 wizard. The wizard always sets up a dispinterface (not a dual interface). So, I got the control working wonderfully and decided that certain performance conditions weren't good enough and am currently switching it to a dual interface. My problem is that I can't get the stock font property to appear in the font property page. A simple switch back to dispinterface causes it to work again... Any idea why?
John
|
|
|
|
|
hello,
i'm having trouble while reading a cd, i insert a written cd and read the directory with a cfilefind. then i eject the cd and put in another. the cfilefind displays the correct new directory. but when i insert a blank cd, the cfilefind returns the old directory of the cd inserted before. but with an explorer opened in the background, i see the cd name disappear from 'my computer' when i eject the disc, and then the cfilefind finds no data on the blank cd. but this only works when the explorer window is opened.
what can i do to get the blank directory instead of the old one without the explorer opened?
i hope, someone could help,
thanks
enrico
|
|
|
|
|
My destructor for a database class I wrote looks like:
~DbClass()
{
Close();
m_pConn.Release();
m_pConn = NULL;
m_strConnection = _T("");
m_pConnPhoto.Release();
m_pConnPhoto = NULL;
m_strConnection1 = _T("");
::CoUninitialize();
}
I have these various connection objects floating around that are created for different databases. I just realized that maybe this destructor is not good. What if I'd already closed the m_pConn elsewhere (I dont)> what if I create some third connection object to a third database locally. Then certainly the local conn name cant be put into the destructor. MAybe that closes automatically when it goes out of scope.
When exactly does the destructor run? When I exit the program? What if some of the objects mentioned in it were already dealt with. it doesnt hurt to close them again? I need all the three (to be) connections to co-exist thats why I didnt recycle the same name.
I hope my problem makes sense. Maybe I'm needlessly confusing myself because things seem to work. I just never thought about it and merrily added the extra conn objects to be dealt with in the same ~destructor (theres alwyas only one, right? )
Thanks,
ns
|
|
|
|
|
The destructor runs in two cases:
1. When the object goes out of scope
2. When delete is called on an object that was created with new
AFAIK, if you create an object using new, and forget to delete it (memory leak), the destructor won't get called.
Hope this helps...
Some examples:
void MyFunc()
{
SomeObject :bob:;
}
void MyFunc2()
{
SomeObject *:bob: = new SomeObject;
delete :bob:;
}
There are three types of people in this world: those who can count, and those who can't.
|
|
|
|
|
Without knowing what resources you are using and how they are being used, I cannot really suggest if the items that you have listed belong in the class destructor. However I can give you some information about when the destructor is called, and that may help you make the decision.
The destructor is called when your object is being destroyed. Your object can be destroyed in two ways.
1) if you created it on the stack like this: Object x; When the object x goes out of scope it will automatically be destroyed.
2) If you created it on the heap like this: Object *pX = new Object; then it will not be destroyed until you call delete pX.
One more tip, unless your object is the thread itself, I would not suggest calling ::CoUnitialize() in the destructor. It is best to call CoInitailze() when your thread or program starts up, and CoUninitialize() when the program or thread is shutting down. If you call CoUnitialize too many times, then the the COM dlls will unload itself for your current thread, and you will not be able to instantiate any more COM objects on that thread.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Hmmm. Threads. Thats a new complication. I only have a single threaded app so I suppose I'm safe. Hope you can confirm this.
As for the dilemma I was having, I had createInstanced all the stuff I was destroying in the constructor (in preparation for potentially using those objects). And I forgot that each new instance makes its own copy of those objects, so one instance going out of scope wont mean that my other instances are crippled because their connection closed etc.)That was a conceptual problem that got me by surprise.
Thanks,
ns.
Though in the process I did learn about static member variables that can be shared betweeen instances....
Thanks,
ns
|
|
|
|
|
It looks like you're using the smart pointers supplied by the #import command (since "m_pConn.Release()" wouldn't normally compile otherwise).
If that is the case, you could remove the "m_pWhatever.Release()" statements and simply replace them with the already existing "m_pWhatever = NULL". The null statement will cause the smart pointer to release the object if it's there, plus an already NULL smart pointer won't care if you set it to NULL again.
John
|
|
|
|
|
Thanks. Yes I am using stuff like _RecordsetPtr etc, so its good to know they manage themselves. I am new at this memory conservation thing and am living in dread that I am doing things that I dont know about that wil make me have memory problems later. So at least I wont have to suspect the database code. The only thing I close when I can in my code is the recordset. I never close the conn object myself, because I keep needing it in various unpredicatble events.
Thanks,
ns
|
|
|
|
|
I created a set by inserting values into it <cstring>
Then I try to find if a new incoming one is already there:
NamesSet::iterator it;
it = namesSet.find(NewName);
If I find it , I want to do something, if not, another thing. To detect it
MSDN says:
const_iterator find(const Key& key) const;<br />
The member function returns an iterator that designates the earliest element in the controlled sequence whose sort key equals key. If no such element exists, the iterator equals end().<br />
So would my test be:
if(it != namesSet.end())
{
}
else
{
}
Thanks,
ns
|
|
|
|
|
Got it exactly right!
Alternatively, you could use one of the insert member functions to insert the new key & tell you if it was a new insertion or not:
std::pair<NamesSet::iterator, bool> res = namesSet.insert(NewName);
if (res.second) {
}
else {
}
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Thanks for the alternative method. more info for me to use with my newly discovered STL.
ns
|
|
|
|
|
Ok, I am working with the RichEdit control and trying to view a file in it. Two questions, first and more importantly why/how is this only reading the first line of the file and no more. How do I get it to read the entire file into the Rich Edit control. Second is how do you allow/tell the control to resize when the maximize button is pressed. Thanks in advance. The code I am using is listed below. Any help in explaining how the call back function works would be great as well, trying to learn as much as I can here.
void CFileViewerDlg::OnSelectFile()
{
EDITSTREAM es;
CFileDialog cd(true);
if(cd.DoModal() == IDOK)
{
UpdateData(true);
m_FileName = cd.GetPathName();
UpdateData(false);
CFile cFile(cd.GetPathName(), CFile::modeRead);
es.dwCookie = (DWORD) &cFile;
es.pfnCallback = MyStreamInCallback;
m_RichEditValue.StreamIn(SF_TEXT, es);
}
}
DWORD CALLBACK CFileViewerDlg::MyStreamInCallback(DWORD dwCookie, LPBYTE pbBuff, LONG cb, LONG *pcb)
{
CFile* pFile = (CFile*) dwCookie;
*pcb = pFile->Read(pbBuff, cb);
return 0;
}
Nick Parker
|
|
|
|
|
how many times is your callback being called?
-c
Though the cough, hough and hiccough so unsought would plough me through,
enough that I o'er life's dark lough my thorough course pursue.
--Stuart Kidd
|
|
|
|
|
You may think this is stupid, but I am not sure where the callback is actually made or what is making the call. Does it only happen when I pass the EDITSTREAM structure in the StreamIn call? I know this sounds bad, but thanks for the help Chris, just trying to learn something.
Nick Parker
|
|
|
|
|
the callback gets hit whenever the control decides it needs some text (ie. it's hard to say without having the REC source code). but, if you stick a break point in that code, you can see when it gets hit.
i'm just wondering if the file read call is failing after first line for some reason - like maybe your file object has gone out of scope, closed the file, etc..
-c
Though the cough, hough and hiccough so unsought would plough me through,
enough that I o'er life's dark lough my thorough course pursue.
--Stuart Kidd
|
|
|
|
|
Chris,
I was reading CRichEditCtrl::StreamIn[^] and it says that the callback function is called repeatedly until the stream is empty, so it appears that I am doing this correctly. I have figured it out. I think I need to officially walk away from my computer right now  . If anyone ever asks you about this problem in the future ask them if they have the multiline proptery checked first.
Nick Parker
|
|
|
|
|
I know I can use CWaitCursor in MFC to do it, but I'm using Win32 and it's being a pain. I tried using SetCursor, but that fails because the DialogBox has an HCURSOR set in the class. And I don't want to change the class cursor, or I'd affect all other dialogs. Then I implemented WM_SETCURSOR, and that works fine. But however, when I move the mouse over child controls (buttons, list view, etc), the cursor changes back to normal until I go over the dialog again. My brain says I have to subclass all these controls, and implement my own WM_SETCURSOR for them, but that seems like a hassle. Is there an easier way?
|
|
|
|
|
Note that you use CWaitCursor for activities which freeze UI. In this case, SetCursor should be enough. CWaitCursor is basically a wrapper over SetCursor calls.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
SetCursor doesn't work, because when I move the mouse, Windows sends a WM_SETCURSOR which basically rewrites my SetCursor call.
|
|
|
|
|
Just like I've posted in my first response, this shouldn't be a problem when you want to show wait cursor during some lenghty, UI-blocking operation. In this case, your app's message queue isn't serviced and code in user32.dll doesn't send WM_SETCURSOR.
Or maybe you want to change the cursor to hourglass permanently?
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Ah yes I understand now. However, my program launches the work in numerous synchronized background threads. Therefore, the queue is still active! I think I'm going to have to subclass all the child controls unfortunately. But it won't be too hard.
|
|
|
|
|
Todd Jeffreys wrote:
But it won't be too hard
Well, it's not too hard. The question is, however, what your users will think about clicking on edit control with hourglass cursor and moving the insertion point to the clicked location
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
If I make changes in a db in code, then reopen the db in another function, (I havent closed it the first time), will the second time its accessed reflect those changes? Each time i LButtonDown I calll an OpenDB() function and because I was having crash problems with exiting, I dont close the database, just reopen it on the next click....
I am not able to test this idea yet, but want to know the expected behavior.
Thanks,
ns
|
|
|
|
|
ns wrote:
If I make changes in a db in code, then reopen the db in another function, (I havent closed it the first time), will the second time its accessed reflect those changes?
Depends on the DBMS and with you are working with transactions or not. In theory, if you commit the transaction the changes should apper in the second open command.
Mauricio Ritter - Brazil
Sonorking now: 100.13560 MRitter
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
