|
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
|
|
|
|
|
Hey! Okay, Im close to convincing my superiors that we should program our next major GUI in VC++ (.NET) I was hoping that you could all please give me a list of your favortie books (and resources i.e. websites) that cover the following:
Asynchronous Sockets
DLL Programming
IPC and Resource Sharing
Firewall Programming (and programming applications that can traverse them)
Win32 and MFC
And answer me this, This gui is going to be large, very big, many features. Should I plan on using MFC or program it Win32 SDK? What would you do?
Ryan Baillargeon
Software Specialist
Fuel Cell Technologies Inc.
|
|
|
|
|
You are asking a key question about program design. I believe program design is more important any any software project than even actual coding. I recommend setting up a design plan for both Win32 and MFC. Afterward determine which one your software engineers can work with most effectively and efficient.
As for books, I highly recommend Programming Windows with MFC Second Edition by Jeff Prosise and Programming Applications for Windows Fourth Edition by Jeffrey Richter.
Kuphryn
|
|
|
|
|
This is my nightmare. So far I have avoided it, but the last thing I did (which I promptly undid thankfully) introduced a crash when exiting. Basically I ended up making a connnection ADO object local instead of a member variable. As the latter, the program crashed. I dont reallly know why. The only thing I can think of is that the local conn object destroys itself when i t goes out of scope.Though I was explicitly closing the member conn object. Thing is even when I didnt close the member conn, just had it declared as a member conn, it crashed.
I'm safe for now. But I am terrified that sooner or later I'm going to do something I cant track down which will make it crash on exit> how do you even start debugging this sort of problem? Please advise me, because I dont want to be helpless when it does happen - I'm dreading it.
Thanks,
ns
|
|
|
|
|
The program crashes when exiting during debug session? If this is the case, just look at the call stack.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
This tells us which function called the latest one right? What then?
I think I need to learn about what the call stack tells us. Any pointers to some goood info on what the call stack reveals, and how to use it?
Thanks,
ns
|
|
|
|
|
ns wrote:
This tells us which function called the latest one right?
Call stack shows all stack trace. Just open the window in VC and you'll immediately get the concept. You may set the debugger context for each function displayed and check local variables.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Just to add to Tomasz's note, you can also navigate to any frame of the stack (by selecting the frame from the combo box). By doing so, you can examine local vars in the previous frames. This is very handy for finding out why your program crashed, since the problem may have actually occured "n" functions before the one that crashed (eg: a NULL pointer being passed to a function that expected a non-NULL one). As usual, ASSERTs help identify these problems early on. Good luck!
PS: Have a safe round-trip. I'm off to NYC to visit friends for the weekend. Might jam with them[^] if I get there in time!
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Ok, this one has me stumped (I'm sure you guys are going to be laughing soon ), if you create a new MFC exe and drag a rich edit control onto your form (dialog based app.), hit the build button everything compiles fine, however when I hit the execute program button the form doesn't appear, nothing happens at all. What little thing did I miss here?
Nick Parker
|
|
|
|
|
Nick Parker wrote:
What little thing did I miss here?
AfxInitRichEdit before your dialog is shown.
Tomasz Sowinski -- http://www.shooltz.com
"Yields falsehood when preceded by its quotation" yields falsehood when preceded by its quotation.
|
|
|
|
|
Check to see the if the visible property of the dialog and/or controls are set to true.
Pankaj
Without struggle, there is no progress
|
|
|
|
|
are you calling AfxInitRichEdit(); in you CWinApp InitInstance ?
you should
-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
|
|
|
|
|
Anywhere in particular, this is what mine looks like which I assume is pretty plain for a new application. I am guessing that I should call it before dlg.DoModal(); or before CFileViewerDlg dlg; is called, does it matter?
BOOL CFileViewerApp::InitInstance()
{
AfxEnableControlContainer();
#ifdef _AFXDLL
Enable3dControls();
#else
Enable3dControlsStatic();
#endif
CFileViewerDlg dlg;
m_pMainWnd = &dlg;
int nResponse = dlg.DoModal();
if (nResponse == IDOK)
{
}
else if (nResponse == IDCANCEL)
{
}
return FALSE;
}
Nick Parker
|
|
|
|
|
I placed it right before CFileViewerDlg dlg; and everything showed up. Thanks again Chris
Nick Parker
|
|
|
|
|
AfxInitRichEdit(); you have to put this line into your apps initinstance.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
