|
|
hah!
You are looking directly at solutions and you do not even realize it.
Sad.
Kuphryn
|
|
|
|
|
|
Cash, in small, unmarked bills. Payment in advance. No refunds. 
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote:
...unmarked bills.
Why would they need to be unmarked? It's not like you are stealing them.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
You don't want the Feds tracing your ill-gotten gains, do you?
Software Zen: delete this;
|
|
|
|
|
If you are being paid for the work, how is that ill-gotten gains?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Sometimes, it is necessary to change a floating point number to an integer. The usual way of doing this is just to write
i = (int)f;
However, the C++ compiler also lets one express this desire like this:
i = int( f );
which is how functions are normally written, and it is easier to understand in complicated expressions rather than casts. Similar expressions can be produced with other implicit types eg double and float eg
dbl = double( i );
Does anyone know when it became possible to write the code like this, as opposed to using casts?
Does anyone know if there are any drawbacks or using this approach?
All comments are welcome
|
|
|
|
|
i had a look at this in the disassembler, didnt find any difference!
Don't try it, just do it! 
|
|
|
|
|
FearlessBurner wrote:
i = (int)f;
Is a cast.
FearlessBurner wrote:
i = int( f );
Constructs an unnamed (temporary) int, using f as the initialiser value, and assigns/copies the value to i. Your compiler probably optimises this.
FearlessBurner wrote:
dbl = double( i );
Is similar to the previous comment, and constructs a temporary unnamed double.
FearlessBurner wrote:
Does anyone know when it became possible to write the code like this, as opposed to using casts?
Does anyone know if there are any drawbacks or using this approach?
It probably became possible to write this when you changed from C to C++.
My own recommendation is to cast using the C++ casts, instead of the C casts, so for the example above I'd write:
i = static_cast<int> (f);
Because it's easier to find casts that use the C++ syntax for casts over the C syntax, and using the correct C++ cast can reduce or highlight potential errors caused by casting - this particularly applies to the other three C++ casts (const_cast, dynamic_cast, and reinterpret_cast)
--
Ian Darling
"The moral of the story is that with a contrived example, you can prove anything." - Joel Spolsky
|
|
|
|
|
I have a Listctrl in which i have to do some operation drags the scrollbar(in either direction)
I know that when user drags the bar SB_THUMBPOSITION is generated.But my problem is how do i know in which direction the scrollbar has been dragged.
Any help will be appreciated
cheers,
Super
------------------------------------------
Too much of good is bad,mix some evil in it
|
|
|
|
|
When you receive a WM_HSCROLL message and the low-order word of wParam is SB_THUMBPOSITION, the high-order word of wParam will indicate the current position. You can keep track of this position and know the direction of the scrolling.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hallo,
has anybody ever encountered a strange problem with LoadImage?
When our application finds bitmap-files with appropriate filenames within a certain directory it wants to use these symbols as treeview icons. We're doing this:
HBITMAP hBitmap = NULL;
CBitmap bmpCmd;
CString strBitmapFile;
strBitmapFile = strCurrentFile.Left( strCurrentFile.GetLength()
-CString(".igl").GetLength());
strBitmapFile += CString(".bmp");
hBitmap = reinterpret_cast<HBITMAP>(LoadImage(NULL,
LPCTSTR(strBitmapFile),
IMAGE_BITMAP,
ImageSize32.cx,
ImageSize32.cy,
LR_LOADFROMFILE));
if (hBitmap)
{
bmpCmd.Attach(hBitmap);
CmdBitmapId=m_ImageList.Add(&bmpCmd, rgbMask);
bmpCmd.DeleteObject();
}
This usually works fine. However, when we start this application from another application with ShellExecute() a few items in the treeview will be displayed without any icons at all. It turned out that LoadImage returned a handle although there was no file with the filename strBitmapFile. The invalid Bitmap was then noted by CImageList::Add which returned an index of -1.
Does anybody has an idea whether we are doing something wrong or whether there is a bug in LoadImage? MSDN reported no such bug.
The workaround is quite easy, I check whether the File exists and attempt to load the bitmap just in this case. This works fine, but still one wonders.
Thanks in advance
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
