|
|
The what is already answered.
The why is: the left side expression is
evaluated purely for its side effect.
Your code must be a paraphrase that's omitting
details which would explain the intent. As it
stands there is no reason for the schmoo, but
the structure is a common one.
In this case "a" was probably, without side
effect, an expression that drove "b" to be
evaluated or not (the && operator evaluates
the right side only if the left side is true,
a conditional short-circuit. That's why the
statement "a && b;" is often used as shorthand
for "if (a) b;")
The author just wanted to scrunch up his code
and place what normally would have been a
preceding conditional statement "if (a) b;"
smack dab in the next conditional
"if (c) blark; else snarf;"
i.e.
"if (a) b; if (c) d; else e;" <-->
"a && b; if (c) d; else e;" <-->
"if (a && b, c) d; else e;"
|
|
|
|
|
What I want to do is make it so that when the user wants to open a file it only shows files of that specific type, that type is .TX0, .TX1, .TX2, ... , .TX9.
Here's my code for the Open Dialog:
<br />
CFileDialog fileDlg(TRUE, NULL, NULL,<br />
OFN_OVERWRITEPROMPT | OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST,<br />
"My Files (*.TX*)|*.TX*|All Files (*.*)|*.*|",<br />
NULL );<br />
I have it so it will show all files of type .TX* but that means .txt files will show up as well as my file types. Is there a way to not show .txt files but still show my files?
There's always one more bug.
|
|
|
|
|
use
"My Files (*.TX*)|*.TX0;*.TX1;*.TX2;*.TX3;*.TX4;*.TX5;*.TX6;*.TX7;*.TX8;*.TX9;|All Files (*.*)|*.*|" <br />
<br />
<div style="padding-top: 12pt; float: left"><br />
<font color="blue">Shog<font color="green"><sup>9</sup></font></font><br />
------</div><br />
<div align="right" style="padding-right: 1em; margin-bottom: -2em; font-size: 8pt; font-family: "Sylfaen"; color: rgba(64, 103, 119, 1)" title="Social Distortion - "Down Here (W/ The Rest Of Us)"">No one's immune now, from a world of problems <br />
No one's exempt now, from a world of pain <br />
That's the way that it goes <br />
when you're down here with the rest of us...</div>
|
|
|
|
|
Thx a lot
There's always one more bug.
|
|
|
|
|
If process A creates shared memory via CreateFileMapping and then process B opens shared memory via OpenFileMapping does the shared memory become invalid when process A exits? If process B stays running and now process C opens shared memory via OpenFileMapping will the shared memory still be valid?
Todd Smith
|
|
|
|
|
Docs are not conclusive, but seems like things behave as you describe. This link[^] in MSDN reinforces this impression.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I believe that if the process that creates the name file mapping exits, the mapping no longer exists.
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Thomas George wrote:
I believe that if the process that creates the name file mapping exits, the mapping no longer exists.
So what happens when the other processes try to read/write the file mapping? KABOOM? Is it possible for the other processes to know when the main process has closed the file mapping? I guess you could create a mutex or something and check that before using the file mapping.
Todd Smith
|
|
|
|
|
Actually, docs say that you HAVE to use Structured Exception Handling because the system could produce access violations (even in situations, when both are active). You will certainly get an access violation when the second app tries to access the shared memory; but I am yet to find out how the second app can find out that the file mapping no longer exists. I am not aware of any events.
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
I believe that because the FileMapping object is a Kernel object, that the file mapping will continue to exist until all handles to it are released.
Here is an excerpt from the CreateFileMapping functions remarks section in MSDN:
To fully close a file mapping object, an application must unmap all mapped views of the file mapping object by calling UnmapViewOfFile, and close the file mapping object handle by calling CloseHandle. The order in which these functions are called does not matter. The call to UnmapViewOfFile is necessary because mapped views of a file mapping object maintain internal open handles to the object, and a file mapping object will not close until all open handles to it are closed.
Build a man a fire, and he will be warm for a day Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul wrotes:
I believe that because the FileMapping object is a Kernel object, that the file mapping will continue to exist until all handles to it are released.
Paul is absolutely right here. A (named) file mapping is a kernel object and will exists, until the last handle to it has been closed. So in your scenarion the mapping will still be present and valid, because at every time there is at least one valid handle to it.
BTW: Using native NT Api it is even possible to make a kernel object "persistent", meaning that it would continue to exist after the last handle to it has been closed (persistent means until next reboot). Of course this makes sense only for named kernel objects. Even if sometimes fairly useful, this is undocumented and therefore "not recommended"
--
Daniel Lohmann
http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there )
|
|
|
|
|
I was trying to build a code sample with UNICODE enabled and it was unable to find MFC42UD.LIB. I found out that the UNICODE libs (debug only maybe?) weren't installed as part of VC6. They are on the CD just not on my drive. I couldn't find any option in the VC6 installer that enables/disables UNICODE libs. Am I missing something or do I just manually copy the libs over?
Todd Smith
|
|
|
|
|
As far as I remember there's actually an option where you can select which libraries you want when you install VC6...
If you select all the VC stuff you get those lib's installed
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Just copy the libs to the vc98\mfc\lib dir
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
I've read the documentation on the compiler error C2668 ('ambiguous call to overloaded function') and it seems that it usually occurs when someone has accidentally introduced an ambiguous function into their own code while overloading a functin. Now, it is possible that I am doing this, but the ambiguous function in question is 'memcpy' and 'memcmp' and the file in question is from Microsoft (c:\program files\microsoft visual studio\vc98\include\comutil.h). Is it possible that this is a bug in MS code? Everything compiles fine, but when I try to link, I get this:
c:\program files\microsoft visual studio\vc98\include\comutil.h(562) : error C2668: 'memcpy' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(568) : error C2668: 'memcpy' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(915) : error C2668: 'memcpy' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(1610) : error C2668: 'memcmp' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(1617) : error C2668: 'memcmp' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(1632) : error C2668: 'memcmp' : ambiguous call to overloaded function
c:\program files\microsoft visual studio\vc98\include\comutil.h(1682) : error C2668: 'memcpy' : ambiguous call to overloaded function
c:\program files\microsoft sdk\include\comdef.h(205) : error C2668: 'memcpy' : ambiguous call to overloaded function
Error executing cl.exe.
-------------------------------------------
Please Help!! What is going on here?
TIA.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
Could you please post the code that is causing the error? Also, I doubt the problem is issued by the linker, this is compiler error.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
That's the problem. The code that the compiler refers to in the error messages is in c:\program files\microsoft visual studio\vc98\include\comutil.h(562).
What I can tell you is this, I have a static library that has ADOX code in it. The application itself is a console application with MFC support. When I build the static library containing the ADOX code separate from the console app, it builds fine. When I put #include "MRDBInsert.h" (which references the ADOX code) in my console application, I get the error described. I'm not even using the code--just including it. That's why I thought it was a linker error--since it builds the .lib file fine. It just won't let the application build.
I know this sounds vague, but I really have very little to go on. If it's any help, I will note that the same static library containing ADOX code will build fine when linked in with an MFC Dialog based application.
Can you tell me what code you would like to see (e.g. the ADOX code, the console _tmain code, or the actual comutil.h file (which is located in c:\program files\microsoft visual studio\vc98\include\comutil.h in my installation))?
Thanks for your help.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
Could you please post the offending line 562 of comutil.h and the context in which MRDBInsert.h is included?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
The offending lines are in bold (comutil.h):
inline _bstr_t::Data_t::Data_t(const _bstr_t& s1, const _bstr_t& s2) throw(_com_error)
: m_str(NULL), m_RefCount(1)
{
const unsigned int l1 = s1.length();
const unsigned int l2 = s2.length();
m_wstr = ::SysAllocStringByteLen(NULL, (l1 + l2) * sizeof(wchar_t));
if (m_wstr == NULL) {
if (l1 + l2 == 0) {
return;
}
_com_issue_error(E_OUTOFMEMORY);
}
const wchar_t* wstr1 = static_cast<const wchar_t*>(s1);
if (wstr1 != NULL) {
memcpy(m_wstr, wstr1, (l1 + 1) * sizeof(wchar_t));
}
const wchar_t* wstr2 = static_cast<const wchar_t*>(s2);
if (wstr2 != NULL) {
memcpy(m_wstr + l1, wstr2, (l2 + 1) * sizeof(wchar_t));
}
}
And here is how MRDBInsert.h is used.
#include "stdafx.h"
#include "MRFileProcessor.h"
#include "MRDBInsert.h"
#include "MRCSVInsert.h"
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
CWinApp theApp;
void usage();
void _tmain(int argc, TCHAR* argv[], TCHAR* envp[])
{
int nRetCode = 0;
if (!AfxWinInit(::GetModuleHandle(NULL), NULL, ::GetCommandLine(), 0))
{
cerr << _T("Fatal Error: MFC initialization failed") << endl;
nRetCode = 1;
}
else if (argc < 2)
{
usage();
}
else
{
}
}
My application structure is as follow:
MRProcessApp - Main Console application
MRProcessLib - Static Library - Contains misc classes
|--------- MRDBInsert.h/MRDBInsert.cpp
|--------- Other class files...
The Worskspace for MRProcessApp contains its own project and the MRProcessLib project. There is a dependency on the processLib in the processApp project.
Thanks for your help.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
Do you in any manner overload memcpy or redefine (through macros, maybe) wchar_t ? This seems unlikely, but the error is truly odd.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I wish. It is odd indeed!! I can't imagine that no one has ever built a console application with ADOX support and haven't faced this error. I can't find a reference to it anywhere on the internet. Google, Google Groups, etc........ Nada!
If you know of any other possibilities, I'm all ears. Thanks for looking at this.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
reinstall vC++ with unicode support libraries. just select
VC++ while instalation and then select upper button above
select all and select all the options the submenu. this
will solve the problem.
seefou
|
|
|
|
|
I've done what you suggested and it doesn't appear to have worked. Is there anything that I need to do in the project settings now to take advantage of what I've installed?
Thanks for your help.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|
|
I never did figure out the problem. Instead, I created a new Console applicatiton. Since my console application simply used classes from my static library, I just pasted the old _tmain code into the new _tmain and linked the library in again. Works beautifully now and I have yet to figure out what is different between the project that won't work and the one that does. Just FYI.
-Matt
------------------------------------------
The 3 great virtues of a programmer:
Laziness, Impatience, and Hubris.
--Larry Wall
|
|
|
|