Comments by Ozer Karaagac

Ozer Karaagac 14-Apr-11 8:23am View

You're welcome. :-)
It entered my head that the files might have been encrypted for only 4GB portion and the rest would still be in unencrypted form. If so, encrypted part (say, first 4GB) could be copied out into a new file, could be decrypted there and could be merged with second part. But the encrypted part might or might not be 4GB exactly, that is, 4 * 1024 * 1024 * 1024 = 4294967296. It might be (4GB - n) where the n might be 1 or any arbitrary number.

The best way to understand this. You can inspect a file grater than 4GB with the help of a hex editor. You should inspect it in both original and encrypted form in order to find out the position where encryption ends.

The second way that comes to my mind, maybe, you can use an enhanced file comparison utility.

Regards,
Ozer

Ozer Karaagac 13-Apr-11 20:32pm View

My 5.

Ozer Karaagac 12-Apr-11 15:53pm View

Thanks, Espen...

Ozer Karaagac 11-Apr-11 23:53pm View

Complete explanation. My 5.

Ozer Karaagac 11-Apr-11 22:40pm View

Greetings, SA...

Ozer Karaagac 11-Apr-11 22:16pm View

Thanks, Albert...

Ozer Karaagac 29-Mar-11 21:00pm View

Not really. I don't have any more useful job to do for now.
And also it would be really a diverse way of returning value from void (though not recommended). I thought, maybe, someone might want to know.

Ozer Karaagac 25-Mar-11 8:39am View

In doc/view, you normally don't need to handle CFileDialog yourself. Framework does this for you and send you selected file name by lpszPathName parameter of above function when you override CYourAppDoc::OnOpenDocument() member.

If you don't want to use Doc/View architecture and want to show CFileDilog yourself, you need to handle ID_FILE_OPEN event in one of your Doc, View, Frame or App derived classes.

Ozer Karaagac 24-Mar-11 23:23pm View

No one shows an interest in your question unless it is in the programming problem domain.

Ozer Karaagac 24-Mar-11 22:38pm View

This one is the more appropriate answer within Document/View architecture.

Ozer Karaagac 24-Mar-11 22:10pm View

:-)
Yes, it provides more accuracy and precision.
It was in my mind when I started to write. Forgot it while considering to append to the end.

Ozer Karaagac 23-Mar-11 10:29am View

Sorry for my misunderstanding. You mean email provider's server name or its user name. :-) I haven't noticed that this is an AOL specific question. I don't know much about AOL, I know "C++" only. Like Emilio said, it may be handled by email client and it may also be stored into a configuration file if you are not sure about registry.

Ozer Karaagac 22-Mar-11 12:40pm View

I posted a reply for your new Q.
http://www.codeproject.com/Questions/171679/Problem-in-Reading-Data-from-stream-of-Structured-.aspx

Ozer Karaagac 21-Mar-11 19:39pm View

Discrete Cosine Transform. A kind of lossy compression.

Ozer Karaagac 19-Mar-11 17:10pm View

I'd like to draw attention to the first two results. Both operate on char. First one decrements a counter, increments 3 pointers and possibly uses direct register addressing. Second increments a counter but possibly uses indexed register addressing. There is a huge difference on i3. Pretty different on my system (2.4GHz Montevina NB). I think, indexed addressing matters. There may be some other factors such as blending.

XOR (1000,1048576) = 933.972893ms
tXOR<char> (1000,1048576) = 1211.190808ms
tXOR<short> (1000,1048576) = 683.663426ms
tXOR<unsigned int> (1000,1048576) = 373.330130ms
tXOR<__int64> (1000,1048576) = 361.271335ms
tXOR<__m128> (1000,1048576) = 170.242587ms

Ozer Karaagac 19-Mar-11 16:58pm View

Deleted

I'd like to draw attention to the first two results. Both operate on char. First one decrements a counter, increments 3 pointers and possibly uses direct register addressing. Second increments a counter but possibly uses indexed register addressing. There is a huge difference on i3. Slightly different on my system (2.4GHz Montevina NB). I think, indexed addressing matters.

XOR (1000,1048576) = 933.972893ms
tXOR<char> (1000,1048576) = 1211.190808ms
tXOR<short> (1000,1048576) = 683.663426ms
tXOR<unsigned int="">(1000,1048576) = 373.330130ms
tXOR<__int64> (1000,1048576) = 361.271335ms
tXOR<__m128> (1000,1048576) = 170.242587ms
tXORo<__m128> (1000,1048576) = 170.447082ms

Ozer Karaagac 18-Mar-11 18:30pm View

Thanks Dalek. :-)

Ozer Karaagac 18-Mar-11 17:52pm View

I don't exactly know but I don't think so. If you don't want to use MFC, CPallini's solution is right for you. You may want to add it recursion and skipping '.' dirs.

Ozer Karaagac 18-Mar-11 15:18pm View

Thanks SA. :-)

Ozer Karaagac 18-Mar-11 12:49pm View

How do you open the file? Text or binary. I think, it's time to post file open codes here.

Ozer Karaagac 18-Mar-11 9:33am View

You're right. VC6 doesn't and 2008 does. ASCII is better for your aim.

Ozer Karaagac 18-Mar-11 8:02am View

Which cases? I didn't say that empty lines are because of UNICODE. They should be related file open mode. Try this. Save it as UNICODE and in binary mode. But before the text insert two '0xff 0xfe' lead bytes into file beginning. You can do this by using following lines. Beware, file pointer should point to start.

BYTE leadbytes[2] = { 0xff, 0xfe };
file.Write((void *)leadbytes, 2)

You should be able to open the (UNICODE) file in VC++ editor (recent versions, I mean). You will probably post another question regarding two lead bytes when loading it into RE control. :-)

Ozer Karaagac 18-Mar-11 7:11am View

Not at all. In general, you can use WideCharToMultiByte(...) function in order to convert it to any code page you want. If you are using MFC string, you can convert it like that CStringA strAsc(strFromRichEdit). But be careful about string lengths while writing to a file.

Ozer Karaagac 18-Mar-11 6:31am View

Normally you don't have any problem with it. Try open the file with notepad or any other text editor that supports UNICODE. I think, VC++ editor doesn't support UNICODE text files. If you want to save it as ANSI, you need to convert it before saving (maybe vise versa when loading).

Ozer Karaagac 18-Mar-11 6:18am View

Do you build your project using UNICODE character set?

Ozer Karaagac 16-Mar-11 21:57pm View

Conceptually, an interface should (only?) define some behaviors (as with COM, pure interface that is all functions are pure virtual). But, in C++, we can utilize a class in which some of its behaviors pre-defined but one is left as pure virtual that is undefined.

Additionally, we can probably pass an interface pointer to a function and we have to delete that object there in that function. All we have a base interface pointer in hand. If we use this pointer to delete and also its dtor is not virtual, derived classes cleanup can't be done.

So virtual dtors may be used but dtors can't be pure virtual because it must be implemented somewhere and dtors can only be implemented within its class.

Ozer Karaagac 16-Mar-11 20:41pm View

may be necessary to ensure "virtuality" for destructors within derived classes.

Ozer Karaagac 16-Mar-11 20:28pm View

Thank you, --SA.

Ozer Karaagac 16-Mar-11 18:16pm View

Not at all!
I had written pStorage instead of pStream mistakenly. I've fixed it though IStorage doesn't have a Write method.

Ozer Karaagac 16-Mar-11 17:40pm View

BTW, You can also use CFile or CStdioFile MFC classes for file operations if you are using MFC.

Ozer Karaagac 16-Mar-11 13:15pm View

Latter one can be compiled but can't be linked. :-)

Ozer Karaagac 14-Mar-11 6:52am View

Sorry, I made a typo by forgetting parenthesis around &pStg. It should be "reinterpret_cast<void**> (&pStg)". (may be, interference by paste operation, overlooked). Anyway, It must have been corrected by you in order to compile above line without error. Additionally, initializing pointers with NULL is a good practice (pStg = NULL);

When it comes to run-time error. It seems to be a pointer points to an invalid memory address. I don't think that my correction can cause this error. May be, subsequent lines. If I were you, I would try to determine which line caused the error by stepping through the code (by F10 key). Then, you can past that line here. :-)

Ozer Karaagac 10-Mar-11 19:52pm View

Yes, two static controls can be an option. But, much more controls means more resource consumption and may be performance penalty. Subclassing a control for such a specific function is not so tedious especially while using MFC and it can be used across all projects. I'll consider your project suggestion (if I have time). :-)

Ozer Karaagac 10-Mar-11 17:35pm View

OK, but, OP would like to have "some text should be with one font and some text should be with another font". At least two different fonts. Is it possible with SetFont() or WM_SETFONT?

Ozer Karaagac 7-Mar-11 21:03pm View

If you would like to know how to register using OS commands after successful build, you can type this command in the same folder, where DLL file resides in it, at command prompt.

regsvr32 yourdllname.dll

If you ask me how to implement DllRegisterServer() function, I can't know how to because I don't know anything about your project. Depending on your project, you can create necessary registry keys or you can register type library. It is up to you.

Not at all.

Ozer Karaagac 7-Mar-11 18:46pm View

Now you are using .def file right. Because you don't have those functions in your code. You need to implement those functions.

BTW, I didn't understand what you mean by previous comment.

Ozer Karaagac 7-Mar-11 17:55pm View

Do you have such functions in your code?

Comments by Ozer Karaagac (Top 37 by date)