|
I want to modify document data (text) with the push of a button. I wonder how I can get to the document data programmatically "behind the scenes" -- and haven't found anything in the documentation that really tells how to do this.
I've considered using the document classes, the DocTemplate classes, view classes, and even trying to get to the document buffer directly, but none of what I've read has been clear about how to change the document data directly.
Help!
Thanks,
Lamar
|
|
|
|
|
A good part of the time, the reason that there is a lack of information is that those involded with producing the documentation consider it ovious. Unfortunaly that is not always the case.
Now assuming that you are using MFC document/view. There is more than one way to accomplish (what appears to be) you goal.
1) You can use the wizard to create a handler in the veiw class or the document class to handle what happens when you press a button (Actualy you could put the button handler in a number of places but only these 2 would be the proper).
2) If you place the button handler in the view class then you need to use GetDocument() to retreive a pointer to the document. If the button handler is in the document class you already have direct access to the data storage member.
3) Once you have a pointer/reference/direct access to the stored data then you can manipulate any way you like.
This all assumes that you have specified a document class member varaible to hold the loaded document. In the case you described I would assume (ass-u-me) that the file data is stored in a CString class or a CStringArray class.
No matter how the document was stored in memory (your choice), you have control of how it is modified.
INTP
|
|
|
|
|
aboutQ wrote:
I want to modify document data (text) with the push of a button. I wonder how I can get to the document data programmatically "behind the scenes"
Your document data must live somewhere in memory. Since you mention text, I assume it is stored as an array of CString objects.
You should be able to access your document's data by performing operations directly on the CString objects that contain your data.
What exactly is it that you are trying to do?
|
|
|
|
|
Hi all. I have a big problem with an application that when minimized and then restored it somewhat *crashses*. I think it is losing focus, but it seems like it just *quits* after displaying the dialog frame. It is active on the toolbar, but when clicked from the toolbar does not even try to redisplay itself.
This sounds a lot like some memory leak, but everything checks out. I am thinking it might be the heap size used because it does use a lot of dialogs from the MFC Class Wizard and a couple dozen icons. Perhaps it loses its focus because of the amount of items needed to reload? So the question would be, how to prevent it from *crashing* when restoring from the minimize state?
|
|
|
|
|
I have no idea what is going on, but one thing is clear. There is some thing seriously wrong with your code. If you are not using any kind of memory checker then you should download a trial copy of one of the memory checkers avialable online (I use Bounds checker) or use the memory tracking facilities that come with Visual C++ (is a pain to use and require modifing your code).
As for a more direct approach, just set a break point in your WM_SIZE message handle and step from there. If you do not have one, use the wizard to create one. This may or may not help you find the problem, because it is possible that the problem may have nothing to do with restoring but occured when you minimized the application (or even before that).
Good luck!
INTP
|
|
|
|
|
I think that might be a little helpful. I have checked into memory programs, but I use deconstructors to destroy everything allocated in addition to freeing memory before reusing it. I am confident in most memory allocations, but think it might still be memory leaks. I did try tracking from WM_SIZE->Restore point and didn't think about minimize.
Its funny because it happens when I maximize and restore to normal size on occassion too. I managed to fix this by not handling the WM_SIZE message, but still the same from minimizing. I'll have to track what routines it is calling when minimizing in the debugger. I also removed a lot of the initializing codes I have (making it like a dummy dialog), but still the same results. It has to be the heap size and am not sure how MFC allocates its precreated resources. Thanks for your help!
|
|
|
|
|
Using CADORecordset:
//m_adorec - CADORecordset
m_datagrid.SetRefDataSource(LPUNKNOWN(m_adorec.GetRecordset()));
but the next string does not work 
//m_rec - CRecordset
datagrid.SetRefDataSource((LPUNKNOWN)m_rec. );
What to do?
bilas aka freshman
|
|
|
|
|
I know I've seen posts about this in the past, but I haven't for a while, and I searched for a while before the weekend and couldn't find any old ones that helped me out. I am using CArchives to read/write to my application's data files. My data files, which are shared over a network (so more than one instance of my application may use them) begin with "recently changed" data, and then are followed by persistent data. This way if my application has already loaded the persistent data, it must only look through the "recently changed" data to update alterations. My question is, I need to be able to work with these datafiles easier. I need to be able to insert instead of always overwriting data. It would be nice map the files if possible so I can quickly jump to areas. Unfortunately, I don't know how to do this, so just a little help would be appreciated! Thanks a ton
Douglas A. Wright
dawrigh3@kent.edu
|
|
|
|
|
1. Keep data according to their usage in one directory but separate files
2. Keep data in one file but "label" it. E.g: phone numbers are stored from byte x on and each entry is 15 bytes long, names from y and 30 bytes ... Use SetFilePointer for positioning.
3. Use a the most obvious: a database
Peter Molnar
|
|
|
|
|
Hi people !
Just stopped to ponder if Microsoft actually missed this critical point in their designs: is it really impossible to specify the icon or bitmap of a button in a dialog template beforehand ? Must I use run-time creation of a button and splat the icon over it in there ? And is there a method to size the button to it's contents ?
At least I can't find an option in the preferences of a button control to specify it's icon.. Very odd..
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
1) "Just stopped to ponder..."
No I do not think micosoft missed a critical point. Remeber that icons and bitmaps basicaly did not exist when the first version of Windows was created. Both Microsoft and Apple (and who ever) had to creat the specifications before they (existed) could be used.
Now they could have changed the format for the dialog template class to include icon/bitmap for the buttons (for all I know they did).
2) "And is there a method to size the button to it's contents "
I have notice that some controls do adjust them selfs to it's contents (this may be an MFC thing).
I recommend that you look at "The Win32 Foundation Classes" by Sam Blackburn here at code project. I know there are other articles out there on this subject (maybe at programmerhaven.com).
INTP
|
|
|
|
|
Thank you for your answer.
However, I think you've misunderstood me here. As far as I know, Windows 95 did support bitmapped/iconed buttons already, at least the requirement for the SetIcon method of CButton requires Windows 95 or later. I somehow find it an impossible idea that someone would still develop software for Windows 3.11 or earlier.
When you edit a button's properties, there is a possibility to specify the flag BS_ICON or BS_BITMAP for it. But there lacks a field to specify the resource used for this button. I ended up into a solution to create one icon control, and specify the sizes of the buttons according to that. Then I used the SetIcon method to load & specify the icon resource for the button during the creation of the dialog.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
"impossible idea that someone would still develop software for Windows 3.11 or earlier"
Not develop, but maintain/add functionality. It was not until this last year that they finaly allowed me convert it to Win32 (95 or later).
I've been writting software since before windows existed.
As for button properties, may be it was just there way of resource code changes. After all adding a couple of new bit flags is simple and should not break any of the existing programs. Microsofts development teams do seem to have good reasons for most of the things they do, it is just hard to figure out (at times) what those reasons where. A lot of what they did was neccesary to avoid breaking old code and make it easier to convert old 16 bit Windows code to 32 bit Windows code. You'll notice that there are many references like "This is included to support... When developing for Win32 you should funcX".
INTP
|
|
|
|
|
Hi I subclassed Cimage and put a handler in it for mouse clicks.
Best Wishes,
ez_way
|
|
|
|
|
I have some timers set in an SDI app. At the moment, I have to click a button to kill the timers before I close the app.
Does the framework kill the timers if I click on the x in the upper corner to close? Or do I need to kill the timers before I close it?
If I have to kill them, what message do I need to catch? WM_CLOSE?
Its view is CFormView.
Thanks!
|
|
|
|
|
Use KillTimer(m_nTimerID);
Peter Molnar
|
|
|
|
|
Thanks for the reply, but that wasnt my question.
|
|
|
|
|
SetTimer is CWnd's member function, happens nothing extraordinary (i.e. no memory leak or anything bad) if you don't kill it separately. The framework does this for you when the CWnd object gets destroyed from which you called it regardless whether you called it from your view or framewnd or whatever place.
As for handling WM_CLOSE in your mainframe, this is a good place for things to clean up that require clean up.
Peter Molnar
|
|
|
|
|
Thanks! Thats what I needed!
|
|
|
|
|
I notice that Peter Molnar gave you the answer, but I consider it a good practice to kill the timers youself instead of depending on the frame work to do it. One of the reasons for this is that you have control and can close it when it is know longer needed, instead of letting it run after its' job is done. The second reason is that unless it is need to run during the life time of the object, it should be killed because it is still generating timer messages and wasting processor time.
INTP
|
|
|
|
|
how can i get the content of password edit box ( this edit box is located in other program) .
thanks !
|
|
|
|
|
there are many programs out there!
Don't try it, just do it! 
|
|
|
|
|
You should send this particular password style edit box a WM_GETTEXT message.
The problem is that if the sender is an external app and the control a password box then you will not get any useful info.
Solution: force (!) the external app calling SendMessage itself.
Look up CreateRemoteThread
Peter Molnar
|
|
|
|
|
This sounds too much like a hacker attempting to steal passwords.
If this isn't the case, could you elaborate?
|
|
|
|
|
Ya, it does! But the information is already on the net and even though I did not care how it was done, I was happy to find a program that allowed me to point to my password entry field in order to find out what password I had used. So I could write it down and use it from work as well as home.
The fact that it is possible does worry me a little, since I now know that (given my posision in the company) I can get any password that anybody told thier computer to remember. If I wanted to I could probubably access it from the machine setting on my desk.
INTP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
