|
How to store an HTML page with the use of serialize function of the document class in and SDI applicaition? Any code for that?
|
|
|
|
|
Whenever I do a build, say a Release build, the wrong referenced assemblies (the Debug versions instead of the Release versions) get copied to the target directory. In fact, the Debug versions of the DLLs will get copied to the target directory in both Release and Debug configurations - usually. I can get Visual Studio to reverse this behavior by removing the DLL project refrences and re-adding them while in Release build configuration. Now the Release versions of the dll assemblies will be copied to the target directories during both Release and Debug builds. Does anyone have any idea what is going on here???
Note that, in spite of this weird behavior, when I view the properties for a particular assembly referenced in any given project, the file location is always correct; that is, it will be in the /Debug folder in Debug configuration and in the \Release folder in Release configuration.
|
|
|
|
|
if you want it to overwrite the old link version every time you run a new compile?
Thanks.
William
Fortes in fide et opere!
|
|
|
|
|
Don't know exactly what you mean, but link incrementally off?
|
|
|
|
|
What's the use of that. The compiler will pruduce the same object files for the files that havn't changed. If you change some code the old linke executable will become overwritten automatically!
Blog[^]
|
|
|
|
|
I failed to mention that you have a window remained opened from the previous executable.
William
Fortes in fide et opere!
|
|
|
|
|
If you want to build another executable, you have to close the application (the executable itself if its running). If you really don't want that, than you have to change the compiler / linker output path to a different directory.
Hope this helps
Blog[^]
|
|
|
|
|
I've been programming command window C++ programs for quite a while now. I've gotten my feet wet with both MFC and direct API calls for Windows application programming, but I'm not sure which is better. MFC seems easier to get the interface going, but I'm not sure how to interface all the different controls/buttons etc. The API calls seem like they don't let you do everything that you can do with MFC, but they seem more documented in MSDN. Anyways, which way should I go for professional application development. I don't want to learn something that will be useless when I get a programming job after college.
Thanks!
|
|
|
|
|
CorvetteZ0606 wrote:
Anyways, which way should I go for professional application development.
C#, probably 
Seriously, if you're going to use C++, I'd be more inclined to learn MFC, because it's so much easier that I wouldn't expect anyone to start a project NOT using MFC unless they had a seriously good reason to do so. But I am expecting that the number of people writing Windows apps with C++ will shrink, especially for custom software, as more and more people move to C# or (dagnamit) VB.NET.
However, I think that knowing how a Win32 app is put together is an important skill.
CorvetteZ0606 wrote:
The API calls seem like they don't let you do everything that you can do with MFC
MFC is by and large a lot of wrapper classes around the core API, so I doubt that is the case.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
So you think I should move to C#? I'm not very motivated to do so since I already own Visual Studio 6.0. Also, doesn't an application written in C# require .Net to be installed on the computer to be able to run it? What about computers running OSes like Win 2000 without .Net? Can they run an application I write in C#?
|
|
|
|
|
CorvetteZ0606 wrote:
So you think I should move to C#?
I think if you want to be employable you should at least download SharpDevelop and the .NET SDK and learn some C#. I'm in favour of knowing as much as possible, not putting all your eggs in one basket.
CorvetteZ0606 wrote:
I'm not very motivated to do so since I already own Visual Studio 6.0.
VC6 is crap, you should get VC7, even if you only buy the C++ compiler ( that is actually pretty cheap ). VC6 standard compliance is really bad, and VC7 is amazingly good. The STL implimentation is tons better as well. Finally, you'll find a lot more MFC7 tutorials nowadays, I would have thought.
CorvetteZ0606 wrote:
Also, doesn't an application written in C# require .Net to be installed on the computer to be able to run it?
Yes. this is a much bigger problem in the minds of people who don't use .NET than it is in the real world.
CorvetteZ0606 wrote:
What about computers running OSes like Win 2000 without .Net? Can they run an application I write in C#?
Yes, both XP and 2000 require downloading and installing the .NET framework before a C# or VB.NET app will run on them. In this day and age, how many people have trouble getting a 30 MB file ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
VC6 is crap, you should get VC7, even if you only buy the C++ compiler ( that is actually pretty cheap ). VC6 standard compliance is really bad, and VC7 is amazingly good. The STL implimentation is tons better as well. Finally, you'll find a lot more MFC7 tutorials nowadays, I would have thought.
Try VS2005! This one is great, comes with free express versions (or very cheap) of C++ and C#. Also, you can use winforms and MFC together.
Blog[^]
|
|
|
|
|
The VC++ .NET Express edition doesn't come with MFC.
Regards
Senthil
_____________________________
My Blog | My Articles | WinMacro
|
|
|
|
|
 I didn't know that, but that's not a really big problem, since it ships with the beta 2.
Blog[^]
|
|
|
|
|
I have it, but I was talking about stuff that is out now, and anticipating that he didn't want to spend a bundle ( why else lumber yourself with VC6 ? )
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
If you can live with the bugs, the beta is a fine product. It has all the team edition features and it is free.
Besides that, he is a student and students should learn the technology of the future. Not the almost trivial things that were nice to know a lot of years ago..
Blog[^]
|
|
|
|
|
I am an MVP, I had no idea it was freely available ( I get them in the mail ). He should also know that the betas expire in time, he could be locking himself in for something he can't afford.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
He should also know that the betas expire in time
I didn't know that... I'll have to use my account on the MS AA server again
Blog[^]
|
|
|
|
|
Hello,
You can't learn something specific in college and expect that you can choose a wide variety of jobs after you graduate. The skills required by every job are very diverse nowdays so it's best to learn something of eveything. College is great for that, I don't think that you get an oppertunity for learning so much different things when you start working for salery. Your employer will only care about executables and the money it's going to cost him.
To the point. I think that MFC is good for learning and building large applications. Before you really know how to use it, you'll have to study on that really hard, but it's really nice to spend some of your time on.
Win32 API's are good to know too if you want to know how windows really works. There is one catch though: we are about to move on to the next generation processors in a moment. The 64 bit processors. MS will develop a complete new API for this and after a few years, your knowledge of the Win32 API will almost be useless.
If I may advise you, try and learn some managed language. C# is a very nice language for rapid development. You'll get your app up and running more fast than you'd ever imagine.
Managed C++ is also something worth to look at. .NET is going to be the main development platform for windows in the future.
I read that you own a copy of VS 6.0. I think that you should download VS 2005. The beta is free available and some express editions will be very cheap or even free after the official release. I currently use this IDE for some programs and it is great! Way better than VS 6.0
These are just the thoughts of a almost graduate student who was headstrong and thought that VS6.0 would live forever... Hope that you find this information usefull.
Blog[^]
|
|
|
|
|
MFC is a wrapper around the WIN32 API. So, by learning WIN32 API it should make it easier to use MFC. As for a job, that's very dependent upon the company. There are some that may require MFC (We don't generally) and there are some that would require WIN32 API over MFC (If you do Windows programming, we perfer WIN32 API or at least some understanding of it as opposed to MFC generally or at least some understanding of how everything works underneath).
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
I am attempting to read the file Summary Information from some JPEG files. I am using the StgOpenStorageEx() to get an IStorage interface to use to get a IPropertySetStorage which is used to open the propertyset. When I run the below code everything works just fine when I have a MS Word document. When I run the same code against a JPEG file file the IPropertySetStorage::Open returns a file not found. If someone could offer some advice it would be greatly appreciated.
http://msdn.microsoft.com/library/?url=/library/en-us/stg/stg/ipropertystorage_ntfs_file_system_implementation.asp
// SummInfoDemo.cpp : Defines the entry point for the console application.
//
#define WIN32_LEAN_AND_MEAN
#define UNICODE
#define _UNICODE
#include <iostream>
#include <tchar.h>
#include <ole2.h>
int _tmain(int argc, _TCHAR* argv[])
{
TCHAR szFileName[MAX_PATH];
printf("Start Demo\n");
if(argc != 2)
printf("usage: summinfodemo filename\n");
else
{
_tcscpy(szFileName,argv[1]);
_tprintf(_T("%s\n"),szFileName);
}
IStorage *pStorage = NULL;
IPropertySetStorage *pPropSetStg = NULL;
IPropertyStorage *pPropStg = NULL;
HRESULT hr;
hr = StgOpenStorageEx(szFileName,
STGM_READ | STGM_SHARE_DENY_WRITE,
STGFMT_ANY,
0,
NULL,
NULL,
IID_IPropertySetStorage,
reinterpret_cast<void**>(&pStorage));
if(FAILED(hr))
{
if(hr == STG_E_FILENOTFOUND)
printf("File not found.");
else if(hr == STG_E_FILEALREADYEXISTS)
printf("Not a compound file.");
else
printf("StgOpenStorageEx() failed w/error %08lx\n", hr);
return 0;
}
if(SUCCEEDED(hr))
{
hr = pStorage->QueryInterface(IID_IPropertySetStorage, (void **)&pPropSetStg);
if(FAILED(hr))
{
printf("QI for IPropertySetStorage failed w/error %08lx\n", hr);
pStorage->Release();
return 0;
}
}
if(SUCCEEDED(hr))
{
FAILS HERE ---> hr = pPropSetStg->Open(FMTID_SummaryInformation, STGM_READ | STGM_SHARE_EXCLUSIVE, &pPropStg);
if(FAILED(hr))
{
printf("No Summary-Information - w/error %08lx\n",hr);
pPropSetStg->Release();
pStorage->Release();
return 0;
}
}
if (SUCCEEDED(hr))
{
struct pidsiStruct
{
char *name;
long pidsi;
}
pidsiArr[] =
{
{"Title", PIDSI_TITLE}, // VT_LPSTR
{"Subject", PIDSI_SUBJECT}, // ...
{"Author", PIDSI_AUTHOR},
{"Keywords", PIDSI_KEYWORDS},
{"Comments", PIDSI_COMMENTS},
{0, 0}
};
int nPidsi = 0;
for(nPidsi=0; pidsiArr[nPidsi].name; nPidsi++);
PROPSPEC *pPropSpec = new PROPSPEC [nPidsi];
PROPVARIANT *pPropVar = new PROPVARIANT [nPidsi];
for(int i=0; i<npidsi; i++)=""
="" {
="" zeromemory(&ppropspec[i],="" sizeof(propspec));
="" ppropspec[i].ulkind="PRSPEC_PROPID;
" ppropspec[i].propid="pidsiArr[i].pidsi;
" }
="" hr="pPropStg-">ReadMultiple(nPidsi, pPropSpec, pPropVar);
if (SUCCEEDED(hr))
{
for(i=0; i<npidsi; i++)=""
="" {
="" _tchar="" svalue[1024]="{0};
" std::string="" strtemp="pPropVar-">pszVal;
printf("%s\n",strTemp.c_str());
pPropVar++;
}
}
}
pPropSetStg->Release();
pPropStg->Release();
pStorage->Release();
printf("End Demo\n");
return 0;
}
Thanks In Advance
Anthony Baker
|
|
|
|
|
Hi guys
I've been consulting with this community regarding the handling of large data files and searching stuff in them. The search process using a multimap works wonderfully. HOWEVER, the actual reading from the disk is painfully long. At some point, somebody said something about not using cout because it abuses the buffer... or something like that. I know you don't use cout to read from a file... but since a stream object from the class ifstream created to read a file
is equivalent to cin... and streams work through the buffer, it still made sense to me that using ifstream may not be the fastest way to read data from disk.
SO... I wonder, is there a faster way to read data from a file that is not using the ifstream? I know that I could use the netCDF system... but I don't have time right now to learn how to use it. So I'm looking for something more direct and simple that is already embedded within C++.
Please, in your response, can you include a simple code to exemplify the use of the alternative?
Thanks a million... you guys rock!!! 
|
|
|
|
|
ifstream may well be slow if you use it to read information in a typed manner. If you just want to read a big blob of info into memory, then you may want to look into memory mapped files ( basically you become able to reference a file as if it was a chunk of memory, the Richter book on Windows C++ development covers this, but I forget the details ). Or you may want to use a C style file object to read the file into memory as one big chunk. I recommend trying all possible approaches, and timing them to see if performance is improved, if not, I'd stick with iostream.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Hi
Sorry, I learned C++ by myself and never went through C. What do you mean "C style file object to read the file into memory as one big chunk."? 
Thanks a million!
|
|
|
|
|
In C ( which C++ is built on ), you use a function called ( I think ) OpenFile, and get a FILE object back. That's what I meant.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
