|
use:
ShowWindow(SW_HIDE); <- will hide the application from task bar
check winuser.h for further options
most useful
SW_NORMAL
SW_SHOWMINIMIZED
SW_MAXIMIZE
you can do this is MainFrm
then use your TrayIcon controller to open and close the application.
p.s it does drop the use of ram a lot and also cleans up the task bar
does fill up the systray but windows hides those 
|
|
|
|
|
No, a tray icon must be owned by a window. And besides, a tray icon is not a window, so "pointing" to a tray icon doesn't make sense.
|
|
|
|
|
Is there ne problem in the code below:-
Critical_Section cs;
main()
{
EnterCriticalSection(&cs);
EnterCriticalSection(&cs);
LeaveCriticalSection(&cs);
LeaveCriticalSection(&cs);
}
|
|
|
|
|
Why are you entering and exitting the critical section twice? Critical sections are designed for exclusive entry into a location with threads, similar to a mutex, but the command issued to the cpu is a lock memory routine not a mutex counter resulting in slightly different behavior at the CPU level. I would have to compile to see what the cpu would think of entering and exitting twice, but I would recommend against it, and even if it "were" to work, you would have gained nothing over entering once. Use it like this:
thread1()
{
EnterCriticalSection(&cs);
// protected code here
LeaveCriticalSection(&cs);
}
main()
{
EnterCriticalSection(&cs);
// more protected code here
LeaveCriticalSection(&cs);
}
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
Isn't it a deadlock type situation? I say 'deadlock type' since there will be eventually an exception raised by second EnterCriticalSection(...) as it waits and then times out because the first EnterCriticalSection(...) didn't leave yet.
-- Soyuz
|
|
|
|
|
This won't deadlock but I don't see the reason at all for entering your critical section twice.
It won't deadlock because of that (from MSDN):
After a thread has ownership of a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. The thread enters the critical section each time EnterCriticalSection and TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection once for each time that it entered the critical section.
|
|
|
|
|
tom groezer wrote: Is there ne problem in the code below:-
Such as:
No definition for Critical_Section.
main() does not return a value.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I have aan application that loads dll A and dll B. Now dll A also loads dll B. If I'm correct only one copy of dll A and Dll B will be loaded.
1) How shall the memory map look like given that there is no rebasing.
2) How will the stuff work in case of implicit loading and explicit loading.
3) Suppose the application explicitly unloads the dll A. I dont think dll B will be unloaded. How shall the m/m map be chaged.
4)Any comments if there were static libraries replacing the dlls
|
|
|
|
|
Why would somebody want to do this
typedef string AddressLines[4];
It seems logical to do something like
typedef int xint;
|
|
|
|
|
Because this is the syntax for defining a type that is a table.
|
|
|
|
|
tom groezer wrote: Why would somebody want to do this
Because it's Friday.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
my project - a plugin dll.
but i not have master exe source code.
which can tell me how to get which address call my export function, in this way, i can debug easy and catch exception.
Thanks.
|
|
|
|
|
I think if there's no input,you can make a own input,just as the master exe.
Later buggers harm more.
|
|
|
|
|
|
Yes, but if the EXE that loaded your DLL has no associated debug information, you're not going to see anything useful in the call stack window.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
|
Does anyone have any good examples of C++ code that will sign an XML document without having to use any third party libraries? If so could you please let me know the URL or let me see a copy of the code.
Thanks very much.
|
|
|
|
|
If you are developing on .NET platfrom:
http://msdn2.microsoft.com/en-us/library/system.security.cryptography.xml.signedxml(vs.71).aspx
-- Soyuz
|
|
|
|
|
Hi All,
I have a Multithreaded MFC application having some 210000+ lines of code. The applications works fine almost all the time but I do see rare crashes 
And it occurs only when I am running the application through the IDE or through WinDbg. (The application has been complied using VC++ 2005). The crash has never happened in a Release version, but I am afraid that someday the application will bomb at the critical time.
When the crash happens, the call stack shows that the pointer has corrupted. I am unable to find when and why that pointer has got corrupted. If I insert the breakpoints in the code, the crash never happens, so it is a very dicey situation.
All the thread in the application are created using _beingthreadex API.
Can someone please give me some pointers on how should I detect crash reason?
Please note that since it a proprietary application I will not be able to share the code.
And I am sorry if someone feels that my query is irrelevant, but this issue is really bugging me.
Thanks in Advance
Regards
|
|
|
|
|
|
well said, i agree with you that logging will definitely help thing down...also I assumed our friend is using thread synchronization properly, but it's good you pointed this out....it could be a consumer/produce problem or thread starvation racing issue for all I know!!!
i am sure when our friend get done with this he will be a better analyst for it 
Yours Truly, The One and Only!
|
|
|
|
|
your description of the bug is full of puns like 'give me some pointers' and 'really bugging me' ....lol 
anyways, it sounds like you have a memory corruption problem, there is no easy way to debug this as you said it can happen anytime.
So your first tasks should be to identify reproducible steps,
once you have this you can set your break points at the places where this pointer is getting referenced and see who is doing what.....maybe someone is deleting the memory to the pointer you are trying to access
also does it always crash at the same place, because this will be helpful!
there is nothing wrong with using _beingthreadex infact it's better to use this over the win32 API as _beingthreadex does some extra initialization with the c runtime lib that is not done with the Win32 API
also is your code checking to see that the pointer is not null before using it, etc are you practicing defensive programming techniques thoughout the code or blindly using a passed pointer etc that would result in an access violation and crash your app soon or later!
Yours Truly, The One and Only!
|
|
|
|
|
If he's using a VS debugger it could be that which is causing it to crash... i dont know how debuggers work  but i don't usually trust MS software...
--PerspX
"Nowadays, security guys break the Mac every single day. Every single day, they come out with a total exploit, your machine can be taken over totally. I dare anybody to do that once a month on the Windows machine." - Bill Gates
|
|
|
|
|
no it's not the debugger and it's not MS! I work with both all the time and i can tell you 99.99% of the time it's the code and the developer's fault!
pick up a book or "debugging application" by john robbins if you want to know a bit more about debugging and now debuggers work, rather than perpetuate the misconceptions why not empower yourself???;P
Yours Truly, The One and Only!
|
|
|
|
|
Mark Salsbery
Microsoft MVP - Visual C++
This episode brought to you by the number 3
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
