|
Ash20 wrote: such that whenever you invoke the application exe , it will search whether robocopy exe is present at that place , if not it will copy the robocopy exe which is embedded in the Application exe to required location.
Add this exe as a resource to your main exe. Later on if exe is not found at the required place, dump it there.
Read this --> http://www.codeproject.com/cpp/UpdateResource.asp[^]
Nibu thomas
Microsoft MVP for VC++
Code must be written to be read, not by the compiler, but by another human being.
Programming Blog: http:\\nibuthomas.wordpress.com
|
|
|
|
|
If you have copied the robocopy exe to the user's hard drive, remember to remove it after your program is done its stuff so that the user's system is in the same state (except for what your program did) as before your program.
Also, better check the licensing for Robocopy. It may prohibit you from doing what you want to do.
Judy
|
|
|
|
|
Hello everyone,
I saw a couple of form of assert in code on Windows,
1. ASSERT;
2. assert;
3. _ASSERT;
4. _assert.
Which one is the most correct to use? I saw people always define this to that, and I want to find the root one which is defined by Windows.
I also saw people manually define assert to NULL if macro DEBUG or _DEBUG is not defined, is that necessary?
I feel assert is in a mess and I want to find a clear and unified way for this item.
thanks in advance,
George
|
|
|
|
|
Yes assert is a bit of a mess. One of the reasons for this is that it isn't defined by Windows. It is defined by the C Library but not in a particularly good, reusable or modifyable way. Hence every library writer tends to create their own so now we have several less than ideal assert macros and functions. In the end the choice comes down to: use the one that suits you best, none is really more or less correct, or do what every one else has done and write your own
The third way I suppose is to find another implementation you like and copy it. John Robbin's SuperAssert is certainly the most complete I've come across.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
|
The link doesn't work for me but that sounds OK. assert will be taking an int because it's in 'C' where bool doesn't exist. I would say if you're going to use the existing asserts then use the MFC version with MFC and the C Library version in plain Win32. There is certainly no need define _ASSERT and assert manually to NULL when !_DEBUG. They should already be #defin(ed) to disappear altogether in Release builds.
I understand the value of asserts but I don't personally use them. I know this is a controversial oppinion and not to be taken as advice but I think they're an incomplete or broken concept. One of these days I'm going to work out why they annoy me so much and replace them with something better.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Thanks for sharing your experience, Matthew!
regards,
George
|
|
|
|
|
Matthew Faithfull wrote: or do what every one else has done and write your own
Just what we need, another bloody assert macro!
Steve
|
|
|
|
|
George_George wrote: 1. ASSERT;
2. assert;
3. _ASSERT;
4. _assert.
Which one is the most correct to use?
I use #1 for MFC, and #2 for Win32. If you are curious what each resolves to, if anything, just place the mouse cursor on it and press F12.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Thanks DavidCrow,
I think there is no need to manually define ASSERT and other forms of ASSERT to NULL when in release configuration, right?
regards,
George
|
|
|
|
|
George_George wrote: I think there is no need to manually define ASSERT and other forms of ASSERT to NULL when in release configuration, right?
I've never had the need to, but then again, I'm prejudice.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Hi DavidCrow,
I agree.
regards,
George
|
|
|
|
|
If in the VS environment, I vote for _ASSERTE(...) because it echos the failed expression in the assert dialog that pops up - much easier to see if you should skip it (i.e. a known problem) or actually investigate.
The non-Debug #define s for assert-related macros are usually to allow release-build code to work correctly if the macro includes a statement terminator. For example, if you have the following code:
if( test != value )
MyMagicAssert( test ) The above code might be correct if the MyMagicAssert macro contains a semicolon or expands to something that is scoped by { and } .
If in a release build MyMagicAssert was #define ed to nothing, the code would evaluate to become:
if( test != value )
So without scope or a semicolon, the if(...) would associate to the next line of code, which would likely be an accident. By #define ing the macro to a semicolon or to {} the code compiles and runs as expected.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR> If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong! Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road! See DeleteFXPFiles
|
|
|
|
|
Hi James,
I agree and learn all from your reply, except this point. I think we do not need to manually define _ASSERT to NULL is _DEBUG or not defined, right?
regards,
George
|
|
|
|
|
There are some forms in which enumchildwindows doesn't return child elements, while on the screen I can see statics, labels... for Example in Office word 2003 Tools->Options (You can try with spy++) How to capture this text?
|
|
|
|
|
Do you want to get text of controls on your program or other programs?
|
|
|
|
|
|
For get or set text you need to handle(hwnd) do you have any CWnd of that window if you have you can use of this code if you run this code on your program it change text of all controls to 123 and vice versa for get text of control (if you have code can you show it dont need to post all code)
for(CWnd* pWnd = GetTopWindow(); pWnd;pWnd = pWnd ->GetNextWindow())
{
pWnd ->SetWindowTextW(_T("123"));
}
|
|
|
|
|
I have only hwnd of main window, and enumchildwindows doesn't return any child windows, but I can see them on form. Please read my first post carefully.
|
|
|
|
|
Can you use of FindWindow ?
|
|
|
|
|
Hi All.
I have a problem regarding disappearance of cursor.
Lets say, I have 2 windows [or Text editors] in an application. I also have a frame that take care of some HTML pages.
Now, when I swap in between above mentioned 2 windows, I used to get a cursor on the clicked window.
----PROBLEM----
In case I have the focus on Window 1 and then if I click on the frame, my focus still stays on Window 1. Cursor disappears, thats normal. But when I click back on this window, I am not able to get my cursir back. Also, in that case, if I click on Window 2 and then back on Window 1, I get muy cursor back.
Any pointer/hint will be helpful.
Thanks
PanB
|
|
|
|
|
Hi,
I need to somehow make my dialog start up hidden. I have a line of code in my own DoModal function that creates the dialog and then executes my own function, which fades the window from completely transparent to opaque. Unfortunately, the CreateDlgIndirect function (which is used to create the dialog) has to be executed BEFORE my fading function, since my function needs to access the created window to do the fade. But what happens is, the window is created and made visible, and THEN my function is executed, which results in a nasty flicker before the fading. Here is my line of code:
if (CreateDlgIndirect(lpDialogTemplate, CWnd::FromHandle(hWndParent), hInst) && CloseSmoothly(m_hWnd, FALSE))
Now, I'm wondering if there is any way to modify lpDialogTemplate so the dialog starts up hidden and nothing flickers. I've tried lpDialogTemplate->style=SW_HIDE , except I get an error: error C2166: l-value specifies const object .
So, is there any way to stop the CreateDlgIndirect function from making the window visible after it is created?
Thanks in advance.
|
|
|
|
|
Have you tried:
lpDialogTemplate->style <big>|=</big> SW_HIDE
??????
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|
|
I get an error when I do that. The error says "l-value specifics constant object."
|
|
|
|
|
I think the error comes because the parameter has to be set before creation. For example, I use it (like that) in my CChildFrm inside PreCreateWindow(CREATESTRUCT& cs), but this is not valid for dialogs, just for views/windows (I'm not 100% sure about this last sentence).
I can not tell you a right solution, but a bypass/trick that could work is to use the MoveWindow or SetWindowPos inside your OnInitDialog and set the coordinates in a value that ensures it goes outside the area of desktop, or do it so small that is not seen.
For example.
BOOL CMyDlg::OnInitDialog ()
{
MoveWindow (3000, 3000, width, height, FALSE);
MoveWindow (0, 0, 1, 1, FALSE);
}
Hope it helps
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
|
|
|
|