|
i'm sure that this bug is ur own bug... i've never heard about such a problem!
Don't try it, just do it! 
|
|
|
|
|
While it's not the cause of your problem, how about replacing
strBitmapFile = strCurrentFile.Left( strCurrentFile.GetLength()-CString(".igl").GetLength());
strBitmapFile += CString(".bmp"); with
strCurrentFile.Replace(".igl", ".bmp");Also, casting the second parameter to LoadImage() is unnecessary as CString provides a LPCTSTR operator.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Make sure your image list is marked as shared.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
Make sure your image list is marked as shared.
Sorry, what do you mean with a shared Image List? Shared with what?
Btw. the image list in question is a simple CImageList - what sort of CImageList property do you mean with shared?
And what could any property of my image list have to do with LoadImage returning a Bitmap handle when the requested file doesn't exist? The problem is not the image list, it behaves absolutely correctly.
Or do you mean the LR_SHARED-option for the fuLoad-Parameter in LoadImage? According to documentation, one shouldn't use LR_SHARED when loading from file. It wouldn't make sense anyway, since there can only be one bitmap for each file and each file would have its own bitmap. So the bitmap wouldn't be shared (even if it was there which it isn't).
Sorry if I misunderstood you.
Thanks
|
|
|
|
|
I'm writing an MFC app (the first large project I've ever done) and originally it was quite small, I was using only 1 dialog box. This app, in the end, creates a text file which is then used as input to another program... Anyway, when I first started this, I had the dialog box create a text file, storing all the information that was entered into it (ie. in the edit boxes, etc...) in it's OnOK() function. This text file was then later used to both restore the information if the user re-opened the dialog box, and as the final file produced by the app.
Now, my app has grown in size, and I originally stuck to using these "intermediate" text files to store the information for each one. Then right before my app closes, it writes all the data from each of these intermediate files into one large file which is used as input to the other program. At first I didn't see this as being a problem, but yesterday I realized just how much file reading and writing I'm doing, and I began wondering if I should find another way to store the information between instances (if that's the right word?) of a dialog box.
I came up with the idea of using a different structure for each dialog box, which will be used to hold all the information obtained by the dialog box.
So, I guess my question is, should I switch from using all these little files, to using a bunch of structures? Something tells me that I should switch to using structures, but I want to be sure before I go ahead and do it.
|
|
|
|
|
One option in MFC would be to create a serializable list of CString objects. Then you would serialize and de-serialize this list to and fro from the file.
Serialization helps to decrease the file size a bit, so perhaps you'd want to consider that. If you would create a class which has CString objects and an ID field, you could keep track of what instance of the program each object of the class belongs to.
I wouldn't recommend structures: like I said, use classes derived from CObject that have dynamic creation implemented and contain appropriate data members (CStrings & ID). Then just let serialization worry about saving/loading them.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I've been reading a bit about serialization and I think you're right about me using that instead of my multiple files I've created or using structures.
I've never used serialization before and I didn't even really know what it was until you mentioned it, so I have a couple questions. Would I be serializing the member variables within each dialog box? lets say I have 5 different dialog boxes...
After all 5 of these dialogs have all been opened, had information put into them, then get closed (but the program itself is still running), am I still able to access the information that was put into them? (I still need to create one file at the end of program execution, I just wanted to get rid of all the little 'in between' files)
Thanks.
|
|
|
|
|
After reading your answer to the other poster, I got a fairly good idea what you are doing.
I assume that you have this one program (thread) running, which is responsible for creating the dialog boxes. This thread has the CMainFrame class, which is the parent of the dialogs. If this is the case, the most efficient way is, like you first theorized, to create one new class: CDialogData.
This class would contain one or more CString members and if necessary, an ID variable of type UINT or similar. Then, you declare an array of pointers (5 sects) as a member variable of the parent class. As each dialog can access the parent class's members via cast-operators and GetParent, each dialog can create a new object of CDialogData on the heap and save it's address to the array of pointers.
This method would require minimalistic changes to the code itself: only the CDialogData declaration and the necessary modifications to the OnOK methods in question to create an object of CDialogData instead of saving to a file. At the end of program execution, the CMainFrame could go through the list of pointers and attempt a save of the member variables into a file if the pointer is valid (non-NULL).
I first thought that the dialog boxes are seperate programs running on seperate threads, in which case you would require inter-process communication or the file-saving technique.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
I am going to have to disagree with the other poster and say do NOT use serialization!
What I would do (and have done) in your position is to make some general purpose classes. How specific is your data? You could make a class that knows how to read/write itself, and has members for all the data. Or you could write a more generic class, that can take name=value pairs (such as an INI file.)
An example of a simple interface for a class that might look like something you'd use:
class MyData
{
public:
bool ReadDataFromFile(CString filePath);
bool WriteDataToFile(CString filePath);
void SetSomePieceOfData(CString data);
...
private:
CString somePieceOfData;
};
The reasons I would avoid serialization:
1. It is a nightmare if you ever want to change your file format, or, heaven forbid, you need to access these files from some other non-MFC program.
2. It is difficult to debug. A text file, you can just open it in Notepad and figure out what is going on. Not as easy with serialized data. It is not impossible, there are tools to do it, but it is a pain.
No single raindrop believes that it is responsible for the flood.
|
|
|
|
|
The data I'm using is fairly specific... it did cross my mind before to write some sort of generic file reading/writing class, but my only concern was the number of times that I actually end up reading and writing each file, not to mention the time taken to parse each of these files...
For example:
Say I have 5 dialog boxes. Each of these dialog boxes utilizes it's own file. The file is read from when it's initialized (unless it's the first time it's being initialized, in which case the file is just created), and written to when it's closed (only OnOK of the dialog though). Each dialog box will be opened at least once. When the user is done, they click on one of the menu items in the main menu bar and that causes another file to be created and written to, making our grand total of files 6. This last file is just all the other files combined into one large file, and after the large file is written, all the other 5 files are deleted.
So, my next idea was to create one structure for each of the 5 dialog boxes. These strucures will all be member variables in the CMainFrame class. So now I'm avoiding creating, writing to/reading from & parsing each of those 5 files, but I'm still easily able to create the 1 large file at the end.
So, I still could make the general-purpose file reading/writing class like you suggested, but I still would be performing all these file operations a whole bunch of time... and my little structure idea does seem to avoid all that, but I'm not sure if it's any better...
|
|
|
|
|
Unless you are talking about large quantities of data I would just go with the structure idea.
Art
|
|
|
|
|
Not too large, in total there's about 60-70 ints and CStrings that I'll be needing to store (and maybe a CArray too). So it just seemed almost pointless to create so many files for so little data.
|
|
|
|
|
Hi,
I had an access violation in my MFC application. In the debug mode I saw the message in the Call Stack window as
Data_Write_winbuffer(void * 0x0012e9d4) line 494 + 22 bytes
KERNEL32! 77e802ed()
What does that "+ 22 bytes mean" ?
Can anyone help me out?
Thanks,
Deepak Samuel
|
|
|
|
|
It means that the error occurred at the instruction 22 bytes past the first instruction that was compiled for line 494 of the Data_Write_winbuffer function.
If you have a complicated expression on this line, you can either look at the disassembly for that line and try to work out from that where the problem occurred, or you can simplify the expression, recompile, and try again.
|
|
|
|
|
Hi all,
i like to made a Multidocument .exe where i have the mainframe window with a childwindow and as a second childwindow i like to load a .dll which creates its own dialog. So, how can i fit this upcoming dialog into the MainFrame window as nice as the other child window is fitted in it? I like to have the childwindow dialog at the left and the dll dialog on the right...
Thanks, Mark
|
|
|
|
|
I cannot give you a direct code implementation, but I will discuss shortly on how a MDI program handles it's child windows.
First, we have the frame window, derived from CMDIFrameWnd. Then, you have a set of CMDIChildWnd objects placed in there. The main frame window is a MDI Frame. The child windows function similarly as a CFrameWnd does, except they rarely have toolbar of their own.
So, when in SDI application, a Frame window has one view, then in MDI application, a frame window has many child frames, which each have their own views. Do you understand this ?
Following this logic, the easiest way would be to create a CMDIChildWnd object in the DLL, and create a Form View to fill this window's view. This way, you would have two valid MDI child windows, from which the first would have a normal view and the other one a form view.
I would follow this approach, because I am unsure how a modeless dialog works when it is a child of a MDI frame window. I have never tested it myself. But using the CMDIChildWnd->FormView approach would give valid, working results, as both child windows would then be CMDIChildWnd objects, and would have all the necessary implementation ready for functioning as MDI childs.
When the windows are created, you must position them appropriately using SetWindowPos member of CMDIChildWnd. Just get the client rectangle of the parent frame (CMDIFrameWnd::GetClientRect), divide it to half X-wise, and use these values to determine the size and position of both windows. First window should be from (0, 0) -> (X / 2, Y) and the other from (X / 2, 0) -> (X, Y), where X and Y are the width and height of the client area, respectively.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Yep, thanks. But it is a thirdparty .dll. I don t know if there is an childframe obj in it. Maybe..
Thanks, Mark
|
|
|
|
|
How can i do a search in a DC? I need to determine if there's a certain set of pixels (another, much smaller DC) present in a big DC. How can i do this? I already did some searching on this site and on MSDN but i can't come up with anything usefull.
Thanks.
|
|
|
|
|
There is only one way: brute force
In an MFC implementation, you would use a CDC object and the GetPixel SDK function. The function returns the color of a pixel in the specified point.
You would need to run through the bigger DC in pieces of the smaller DC, comparing each pixel against other.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi All,
I transparentize a window by SetWindowRgn, but I can't control it's alpha.
How to control it? Like SetLayeredWindowAttributes under Win2K.
I want to transparentize a window captured by WindowFromPoint
Thanks.
Xiaobin
|
|
|
|
|
Not doable.
The layered windows are only available in Win 2000/XP and later. You could attempt to creating a window, then making it's whole client area from an image that supports transparency, and paint the background of the window with a NULL brush. This, however, would require you to constantly erase and repaint the background.
Using this method with a WindowFromPoint would require you to subclass the target window, take a screenshot of it's DC, create an image from this DC that supports transparency, then set the background brush to NULL for the window, and repaint it completely with the transparent image.
In conclusion: impossible, get an OS version that supports layered windows or forget the idea 
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi Antti,
Thanks.
I get the address from SetLayeredWindowAttributes from "User32.dll" and set it to a function pointer. If the pointer is NULL, I set the IsW2K false.
I choose the transparent function in this way, am I right?
And, when I move a window transparentized in your method, it seems can't retain transparency. What shall I do?Hook the WM_PAINT message?Or...?
I wrote a program can make window captured transparency under Win2K, but I want it suport Win9x. I found it difficult. -.-;;
|
|
|
|
|
Well, like I mentioned, you can make a program that adds a transparency effect to a window under Win2k. That much is simple. If you want your program to not crash in Win9X, you need to check for the availability of SetLayeredWindowAttributes in User32.dll.
The method I described requires that you subclass the window, get it's class style and variables, then register a new window class with NULL brush and set this class as the window's class. Naturally you need some way to preserve the original window class so you can return it when your program exits.
When a window has NULL background brush, it's background gets painted with the desktop image currently underneath the window when the background is refreshed. You can force a window to redraw itself by issuing a RedrawWindow method call. Of course, you would need to order the window to refresh itself always when it is moved.
This isn't a very working method to force other process' windows go transparent, because you would then constantly need to handle WM_PAINT messages to capture the DC of the window to a transparent image, process it, and re-paint the window with the new image. This adds a big amount of overhead and will certainly slow the program's execution.
Transparency is just not supported on Windows 95/98. You can add transparency for Windows 2000/XP programs and make sure your program works correctly on 95/98 by fetching the address of SetLayeredWindowAttributes and testing the result for NULL. But you can't make transparency effects similar to what the layering can offer on Windows 95/98.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Hi Antti Keskinen,
Thanks a lot.
Xiaobin
|
|
|
|
|
It's impossible.hahahahahah.....
windows98 is rubbish.Bless u.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
