|
thank you very much its solved my problem
|
|
|
|
|
Hi Guys, I am developing a MFC application using Microsoft Visual Studio 2008, i have a strange error, i dont know how to solve it, if any one know pls tell me the reason..
Error 1 general error c101008a: Failed to save the updated manifest to the file ".\Debug\Account Pro.exe.embed.manifest". The parameter is incorrect. mt.exe
|
|
|
|
|
I regularly see the same error with Visual C++ 2010 Express, but a rebuild always fixes it. I suspect some timing issues in the build process that causes mt.exe to fail. I have not researched the solution since it is always recoverable.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I experienced too the same issue. Searching the Internet, I found an explaination of it: the build process basically moves through 3 steps:
- compiling
- linking
- embedding manifest
After the linking stage, you have a new exe file on your output folder, and the Manifest Tool (mt.exe) is called on it to embed the application manifest. If you have an AntiVirus that perform real-time scanning, is possible that immediately after the linking stage and before that the Manifest Tool gets access to the executable file, it find the new executable and lock the file to scan it for viruses; in that case, the Manifest Tool gets the file locked for writing and fails.
|
|
|
|
|
An interesting analysis; but I wonder why it only ever affects the manifest builder and never the compiler, linker or any other program I run?
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
It is not so strange for me: let's assume that the AntiVirus real-time scanner only scan executable files... Then the compiler could not be affected, because it gets source files and produces object files; the linker could not be affected because it gets object files and produce an executable file, but the AntiVirus is not able to scan the created executable until the linker closes the file. Then it seems that the only one tool that could be affected is the Manifest Tool as it gets an executable file that already exists and open it to modify its content.
Anyway, this is the only one explaination that I found, but I'm not sure that it's correct nor that it could be the only one reason for the Manifest Tool to fail... I found too something about this issue on the official technical blog of the VC++ team, and I wonder that they simply said: "after our tests, we was not able to reproduce the issue"
|
|
|
|
|
Yes, that makes sense, I may try modifying my anti virus settings to see if it has any effect.
Thanks for your comments.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Hi,
How to set control ID at runtime?
|
|
|
|
|
You can use SetWindowLong[^] e.g.:
SetWindowLong(handle_to_your_control, GWL_ID, the_new_id);
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> "It doesn't work, fix it" does not qualify as a bug report. <
> Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
|
|
|
|
|
I'm testing in Dialog based Application.
I've remove the default title bar and draw bitmap in client region.
The problem is that when I set menu in this dialog, menubar is appeared at top of screen ,above of the bitmap titlebar.
How can I change the position of Menubar?
|
|
|
|
|
If you're not using the default title bar and drawing your own, then you will need to do the same in the case of its menu also.
You will need to draw the menu yourself and handle the button clicks on the menu items.
|
|
|
|
|
Is there anyway to create an Office 2010 style ribbon (Aero tabs and Backstage) with Microsoft's Windows Ribbon Framework?
|
|
|
|
|
Hi,
The accurate answer is no.
The current Windows Ribbon Framework formerly known as Scenic Ribbon has limits, at least:
- no built-in support for MDI maximized icons (near the help button in Office),
- no expansion button bottom right of tab groups,
- application menu not expanding to full window size as Office Backstage.
Usually the Office controls are one step ahead the system ones, so we may expect the Office 2010 features in the Windows Ribbon when Office 2014 will introduce new ones
cheers,
AR
Relook your Old and New Native Applications with a Ribbon UI under Vista or Windows 7 (WTL)[^]
When the wise (person) points at the moon the fool looks at the finger (Chinese proverb)
|
|
|
|
|
Gave a program for a friend to test, as soon as he launched he was notified with this error.
The procedure entry point RegGetValueW could not be located in the dynamic link library ADVAPI32.dll.
I went back to the drawing board only to find out that it is only called after the user has interacted with the program.
So it's not something I'm doing during startup of the application!
|
|
|
|
|
There is a call somewhere in your program to this function. The program loader checks all calls at initialisation to ensure the program can execute correctly. It appears that your friend's PC must have a very old (i.e. non Unicode) version of the system libraries.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
The Requirements for RegGetValue are given by MS as:
Minimum supported client: Windows Vista, Windows XP Professional x64 Edition
Minimum supported server Windows Server 2008, Windows Server 2003 with SP1
Is your test running on one of these?
|
|
|
|
|
I thought does was an old function available since Windows 2000.
Any idea how to get a previous older function?
|
|
|
|
|
You can use the RegQueryValueEx function which is available in older OSs.
|
|
|
|
|
You may like to look at RegQueryValueEx()[^].
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I'm trying to create a SafeArray of Variants (min 1000 and max 6000 elements). Initially the array is not going to contain the variants, they will be added later on. Here's the sample code -
<code>
SAFEARRAY *psfaResult = NULL;
SAFEARRAYBOUND rgsabound[1];
rgsabound[0].lLbound = 0;
rgsabound[0].cElements = ElementCount;
psfaResult = SafeArrayCreate(VT_VARIANT, 1, rgsabound);
if(psfaResult == NULL)
{
/*
error handling
*/
}
</code>
What happens is, frequently an access violaion exception is thrown during the creation causing the code to crash. I have a snapshot of the callstack when this problem occurs, but I guess I'll have to type it out -
First chance exception 0xC0000005 ACCESS_VIOLATION occurred at 0x7C911689, read of address 0x00000000 at 0x7C911689 (in C:\WINDOWS\system32\ntdll.dll)
0x7C911689 RtlInitializeCriticalSection + Ox6C in C:\WINDOWS\system32\ntdll.dll
0x7C91A3F5 RtlReAllocateHeap + Ox855 in C:\WINDOWS\system32\ntdll.dll
0x7C911937 RtlInitializeCriticalSection + Ox31A in C:\WINDOWS\system32\ntdll.dll
0x774FD03B IsValidIid + OxFA in C:\WINDOWS\system32\ole32.dll
0x7712AA1B SafeArrayAllocData + Ox3B in C:\WINDOWS\system32\oleaut32.dll
0x7712AAE3 SafeArrayCreate + Ox8E in C:\WINDOWS\system32\oleaut32.dll
I have attempted an alternative of using CComSafeArray as well, which internally uses the same route, hence in vain. The issue occurs only in release mode, 5/10 times.
My feeling is that this is an effect and the cause is elsewhere in the code. However, what I am looking out for is, directions to search the probable causes.
Any insight into the problem will be helpful! Thanks!
|
|
|
|
|
There is nothing wrong with the code. The only place where a problem might occur is the ElementCount variable, if it's zero. I suppose since cElements is unsigned, using a negative value would not present a problem and return E_OUTOFMEMORY. I don't know how the API will respond to that, but if you have made sure it's within valid bounds, the code should work as written.
Edit: Do you use your compilers highest warning level?
|
|
|
|
|
Actually I felt the same at first, so I logged the count. The count is as expected when the exception occurs.
|
|
|
|
|
Hi,
I'm using LibTiff to write TIFF files (from multiple threads) in C++, and getting
the following error message:
"Probable I/O race condition detected while copying memory. The I/O
package is not thread safe by default. In multithreaded applications,
a stream must be accessed in a thread-safe way, such as a thread-safe
wrapper returned by TeaxtReader´s or TextWriters´s Synchronized methods.
This also applies to classes like StreamWriter and StreamReader"
(The C++ is being called from a C# GUI, which accounts for the .NET class names.)
The weird thing is that the LibTiff call is in a critical section, which
(theoretically) should avoid race conditions:
DLLEXPORT int writeVariableImage (HBITMAP staticBlackLayer, HBITMAP varLayer,
VariableObject* varObj, int numVarObjects,
char* fileName)
{
if (!criticalSectionInitialized)
{
InitializeCriticalSection (&cs);
criticalSectionInitialized = true;
}
EnterCriticalSection(&cs);
try
{
if (!copyBitmap (varLayer, staticBlackLayer))
throw 666;
HDC memDc = CreateCompatibleDC (NULL);
HGDIOBJ Obmp = SelectObject(memDc, varLayer);
if (!memDc || !Obmp)
throw 666;
for (int i = 0; i < numVarObjects; ++i)
drawVariableObject (memDc, &varObj [i]);
invertLayer (memDc, varLayer);
writeToTiffFile (varLayer, fileName);
if (!SelectObject (memDc, Obmp) ||
!DeleteDC (memDc))
throw 666;
}
catch (...)
{
DWORD err = GetLastError ();
if (err)
{
LPTSTR s;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
NULL, err, 0, (LPTSTR)&s, 0, NULL);
MessageBox (NULL, s, L"Error", 0);
LocalFree (s);
}
LeaveCriticalSection(&cs);
return 0;
}
LeaveCriticalSection(&cs);
return 1;
}
The other oddity is that the error only shows up on 1 out of the 4 computers it's
been tried on. (The computer that shows the error has 4 cores, the others, 2.)
Any ideas what could be causing this, or how to avoid it? Thanks!
|
|
|
|
|
Some ideas to help you track down problem.
1. You seem to have the 'source code'. I would move the critical section initialization outside this function and make damn sure it is already done before ANY thead has a achance to call the function.
2. Make sure no two calls are trying to write to the same file.
3. Increment a local variable along the way - print out its value in the exception handler to get an idea WHERE you had a problem. They currently thow 666 everywhere - not too easy to tell what the real problem is when that is being done.
I would not try too hard to figure out what is wrong without the changes I suggest above, which is what I would do to allow me to diagnose the actual problem.
|
|
|
|
|
Great suggestions! Thanks! (I especially like #1; multiple threads could hit this at once.)
|
|
|
|