Hi, I fight fires when not at work. The local fire department is always looking for people to help out and work hard. They've paid for all my training (100's of hours). They provide the equipment. There is always stuff to do, more training, maintenance on the equipment, etc. It is a very blue-collar atmosphere, and much different from the often solo computer-related tasks of the office. And when the alarm sounds, my work allows me the flexibility to drop what I'm doing, go answer the call, help people, get some adrenaline pumping, work hard, etc. And I can make up the time at the keyboard later on. The fire stuff takes up most of my free time, but I do manage to get out to the mountains from time to time, and just hike back into the wilderness for days on end. Jeff

I'm making a couple of assumptions here, so if this isn't what you're looking for provide additional detail... You can create a CFile, and open it shareExclusive, that will prevent others from working with it or reading it while you have it open. You can then Seek to a specific location within the file, and write your new data to that spot, then close the file. Check out the documentation for CFile. Hope this helps Jeff

Oops, additional info. I'm currently working on Windows 98, but any solution would need to work on Windows NT and Windows 2000 as well. Thanks for any info Jeff

Hi all, I'm in the process of writing a Text Viewer application. Notepad does not open large files, and Wordpad opens them but reads them all into RAM and brings the OS to its knees with the swap files, etc. What I want to do is to open a text file and just read in the portion of the file that should be showing (and some extra for caching, but not terribly urgent right now). Then as the user runs the scroll bar, I would redraw the text that I need to redraw. A future addition to this program will be for other file types, so I wil have a class to work with Text drawing, and then add other classes as necessary to draw TIFF's or our own file format, etc. Unfortunately, as I work with this, I keep running into problems with MFC. I'm working with MS Visual C++ 6.0, SP 4, MFC 6. Using CScrollView I can print the file, and print preview, but when I try to scroll the file on the screen, it chops off the top, or the bottom, or chops the bottom off lines of text, etc. Any thoughts about a good way to go about this? Is ScrollView too much of a "helper" if you're not planning on reading the whole file into RAM? Would CView be better? Should I just scrap MFC and write it using the APIs myself? Any thoughts would be appreciated. Jeff

Yamini, It depends on how you know the members are wrong. If you are using a byte index into the structure and coming up with the wrong values, or if you are looking into memory locations directly, then the problem may be how the structure is defined. If you don't tell the compiler to pack the structure to 1 byte values then when it builds the structure it may pad spaces onto the end of intermediate values to get the 'correct' block sizes. If you have strutures within the defined 'communication' structure, this problem can be compounded. Check that you use the compiler directive "#pragma pack (1)" around your structures to be sure that the compiler is not adding additional empty bytes. Once all the structures are defined you can use "#pragma pack ()" to return the pack value to its previous setting. Just a thought Jeff

I got the following message in reply: Thanx for the ideas !I created a worker thread .I am posting message to this worker thread only ! As you said I am passing the pointer to structure as WPARAM of the message !Now, in the ThreadProc of this worker thread I am typecasting the WPARAM of the message to the structure pointer and retrieve the members of the structure !Here only I am receiving the wrong value for some data members(Of the 11 members the last 4 member values are wrong !)What can be the problem ?I had tried with Mutex & critical section.Still the same problem exists ! How can I overcome this problem ? Regards, Y.Yamini Devi

Yamini, It sounds like you are passing in a pointer to the structure properly, and some of the data is correct. But since the interface thread is still running, perhaps the values that were originally stored in the structure have been changed before you got a chance to read them? (Just a side note to be sure that you use a Critical Section or a Mutex to ensure that one thread is not writing new data to the structure at the same time the other is trying to read it.) I'm assuming that you do cast the WPARAM back to the correct structure pointer when the message is received by the worker thread. If checking on this stuff doesn't help, reply to the post, and I'll try to think of other reasons this may be happening. Jeff

Hi, I'm working on writing a text file viewer. Currently in MFC 6.0. It needs to be able to open text files of any size, so can't load it all into RAM at once. If someone has this written already, that would be helpful. I need to be able to adapt it to other file types in the future, but right now just getting it to view (and scroll) a single file of unlimited size is a start. Thanks for any help.

Hi DiDi, I haven't done this myself, but I have done this with Dialog Based apps, so I am making some assumptions here. In your SDI, in the View class, there is a function OnInitialUpdate(). This function is called after the window is 'created' but before it is actually displayed on the screen. In order to set the window text, the window must exist. But, I understand that you want to set the text before the window becomes visible. The aforementioned function is the perfect place to put such code. In your View class, override OnInitialUpdate(), call the base class CView::OnInitialUpdate(), and then add your code to change the name of your window before this function finishes. Hope this helps Jeff

Thanks Blake, I have no idea why I didn't think of looking at all the members of HELPINFO to find the iCtrlId item. That is exactly what I need, and it works for F1 help as well, so I can trash my previous work around. Just in case anyone is interested, Brad Robinson replied to my post in the CodeGuru Visual C++ forum with a different solution, he suggested grabbing the Window Handle member of HELPINFO (hItemHandle) and then translating that to a Control ID. That works as well. Thanks for the assist Jeff

Hi John, I'm going to guess that you are using the Microsoft Foundation Classes (MFC 6) in the Visual Studio IDE, if this is not true, please specify your environment. If you go to the 'resources' tab in the 'workspace' you can add a new dialog by right-clicking on the 'dialog' folder in that area and selected 'Insert Dialog'. By right clicking on the new dialog box you can fill in the 'properties' of this dialog box. Name it something useful such as 'IDD_MAIN_DIALOG' that you will understand later. (using the IDD_ prefix will come in handy later if and when you want to create context sensitive help). On the dialog put two edit box controls (drag them from the 'controls' tool bar. In the property for each control, fill in the 'id' as something useful like IDC_FIRST_MESSAGE and IDC_SECOND_MESSAGE. (using the prefix of IDC_ comes in handy when you want to have context sensitive help). You can leave the OK and Cancel buttons there or remove them as necessary. Now that these edit boxes exist, Save the whole thing. Right click on the dialog box and selected 'Class Wizard'. It will ask you if you want to create a new class, say yes. You will inherit from CDialogBox. Name it something appropriate. Now when you go back to your 'Class View' tab in the Workspace, you will see that newly added class. You can add a function called OnInitDialog. When the dialog opens, after it is created, but before it is displayed it will run the OnInitDialog() function. You can check parameters here and use the commands 'SetWindowText()' to set up the values in each of the edit boxes before the window opens. I know this is a quick overview, but it should help to get you started, and as you have more specific questions you should be able to find what you are looking for in the documentation or by posting more specific questions out here. Hope this helps Jeff

Hi, I currently have a Dialog based application written in Visual C++ 6.0 SP2 using MFC 6.0 in the Visual Studio 6.0. I am currently on Windows 98 but the app needs to work under Windows NT 4+, and Windows 2000 as well. On the dialog box I have implemented 'F1' help. I did override OnHelpInfo() so that I could specify which control to get help for (standard windows operation is to get help on the 'dialog', not each control). Now I am trying to implement 'Shift+F1' help. When the user clicks on the '?' in the title bar, or presses 'Shift+F1' the cursor changes to the 'Help cursor' and they should get help for the next item they click. In this app the cursor does change properly, but I am having trouble catching the info about the control they click. If I go to my override of OnHelpInfo(), this function does get run but the dwContextId member of the HELPINFO structure is NULL. I checked out the MSDN help and according to technical note 028, the application should post a message WM_HELPHITTEST, when the user clicks the control with the 'Help Cursor', to the CWnd which was clicked, and then to its parent, etc. I have included that message in my Message Map and it does not appear to have been posted because my dialog box is not catching that message. Any thoughts on how I can identify on which control the user wants help? Any info will be appreciated Jeff

Hi, I too have tried deciphering the result of the LIST command for an FTP client. I even downloaded the latest FTP standard, and guess what, the response to the LIST command is not standard. My current thought is just to write the data (whatever they send) to a log file that the end user can view. Then the end user can determine if the 'SEND' was successful or not. If anyone else has a better answer, I'm all ears... Jeff