|
You already asked this question. Be patient.
|
|
|
|
|
Hey, we have money. We can pay for it.
We have to format a SD Data card from with-in a program. It has to be FAT16, and we don't want XP's format dialog box to come up.
We have been searching on several sites that sell C++ libraries, nothing exists! It looks like we will have to go raw and manually format the drive.
Thing is, this code has to have been written a hundred times. It doesn't seem like something we should have to write again.
Does anyone know of a library that can be purchased to do this?
Thanks for the responses - I love the Code Project site!
-Matt
|
|
|
|
|
YOu mean like this[^] ?
led mike
|
|
|
|
|
MSDN: The format is controlled by the dialog interface. That is, the user must click the OK button to actually begin the format—the format cannot be started programmatically.
|
|
|
|
|
No, that opens a format dialog.
|
|
|
|
|
|
I looked at that article and discarded it because:
) It displayed a dialog (I hadn't thought of making the dialog invisible)
) It looks like the user has to press the 'Start' button
) I'm not sure how you would force it to FAT16
-Matt
|
|
|
|
|
TheMattster wrote: It looks like the user has to press the 'Start' button
You can programmatically "click" buttons.
TheMattster wrote: I'm not sure how you would force it to FAT16
In much the same way as the article showed how to set the volume label. Enumerate the child windows until you find the File System combobox.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
TheMattster wrote: It displayed a dialog (I hadn't thought of making the dialog invisible)
Making the dialog hidden is trivial.
TheMattster wrote: It looks like the user has to press the 'Start' button
Nope - that's automated.
It's trivial to automate it.
TheMattster wrote: I'm not sure how you would force it to FAT16
Default is FAT16 (though it says FAT)
|
|
|
|
|
Ok, you can hide the form and populate the fields and simulate the click.
It just seems really clugie to me. All this extra code to try and force something to work a way it is not intended to work.
I'd rather just call a routine.
-Matt 
|
|
|
|
|
TheMattster wrote: I'd rather just call a routine.
Problem is that disk-access is usually done at a lower level. So you won't find an app-level library capable of doing that.
|
|
|
|
|
hi all,
how can we remove desktop shortcut icon programmatically ?
venu
|
|
|
|
|
It's just a file, delete it like you would any other file
|
|
|
|
|
|
toxcct wrote: delete from where ?
The desktop.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
deleting the desktop shortcut from the desktop ?
i think one of us didn't get the question... 
|
|
|
|
|
toxcct wrote: i think one of us didn't get the question...
It's an English thing. In his question, desktop is an adjective, describing the type of shortcut. It would have been the same as, "How can we programmatically remove a shortcut icon from the desktop?"
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hello everyone,
Suppose a program looks like,
--------------------
code block 1;
if (condition == true)
{
code block 2;
}
--------------------
I want to see the state of block 1 (variable values) if condition is true. So I am wondering whether Visual Studio supports backward debugging, if it supports, I could set a breakpoint at the beginning of code block 2, and if it is executed, I could run *back* to the beginning of code block 1 to execute code block 1 again see the detailed running process of code block 1.
thanks in advance,
George
|
|
|
|
|
You can set the execution pointer to anywhere you want, but you have to be careful with this because it can make your code behave rather strangely sometimes.
If you just want to see the variables from code block 1, just use the watch window.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thank you Zac!
I would like to know your comments/advices for my issues below. I have described it in more details.
But in my situation, it is hard to know the condition before an error occurs ... means the condisiton is not predictable and there is not a fixed a rule for defining conditions. The only point where I can find errors is, the execution of code block 2.
In more details, I want to monitor the original values, which will incur the error. For example, code block 1 will be executed a lot of times and code block 2 will only be executed when there are some errors. I want to set a breakpoint to the beginning of code block 2 and find the states of variables in code block 1 when there are errors. I can not set a break point to the beginning of code block 1 since it will be executed a lot of times even if there are no errors ...
regards,
George
|
|
|
|
|
Set a breakpoint at the start of code block 2. Run your application in debug mode. When you reach the breakpoint, use the watch window to look at the variables you need to see (as long as they are in scope). Now, if this is part of a catch block, make sure your variables are declared outside the try block so that you will be able to see them.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Hi Zac,
In code block 1, there are some function invocations, which has some local variables in function stack, such variables can not be monitored outside when returned back to code block 1/2. Any ideas?
regards,
George
|
|
|
|
|
Several. You can set a conditional breakpoint on any of those local variables you want to watch. Or you could add some variables to the scope outside of those calls to just store the values of those variables for debugging purposes. Additionally, you could always add code to output important data to a file as it goes through your code.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thank you Zac,
The idea of setting a conditional break point is not feasible for me, becasue the value of variable which will cause error is not predictable (image some mathematics operations ...).
So, I have to write some additional code to some place, a file or the console. But actually, I do not want to add them since I am debugging some race conditions in a multiple threaded application, and I concern that if I add some additional debug code, the race condition will not occur. And, I only release application without debug code ... I mean I want to test the application the same as the one I will release (without debug code).
Any comments or good points to solve this?
regards,
George
|
|
|
|
|
George_George wrote: The idea of setting a conditional break point is not feasible for me, becasue the value of variable which will cause error is not predictable
But you do know the valid values for such a variable I take it?
George_George wrote: So, I have to write some additional code to some place, a file or the console. But actually, I do not want to add them since I am debugging some race conditions in a multiple threaded application, and I concern that if I add some additional debug code, the race condition will not occur. And, I only release application without debug code ... I mean I want to test the application the same as the one I will release (without debug code).
You may not want to, but you may have to in order to find your bug. You can test your release builds all you want, but if you are not able to find the cause of your bug, you need to start gathering more information. If the race condition does not occur when you add output information, at least you would have tried -- and if it does still occur, you would have more information about where it might be. Debugging is largely trial and error.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
