I didn't notice Wscript.Quit, In my mind I just saw to lines with Echo. That takes all the mysteries out. Thanks again!!

So basically: 1. 'On Error Resume Next' turns on user error handling as the default behavior is to exit on errors 2. If the call to oFso.GetFolder returns an error the function will Echo out the error code and continue execution instead of the normal behavior of exiting This would make since as this is part of an ETL process which is just copying backups to a shared drive. The process doesn't need to stop if the shared drive is unavailable for some reason. Thanks everyone!

Thanks for the explanation. What you said makes perfect sense. I still don't understand why you would do this: Set zGetFolder = oFso.GetFolder( sFolder ) When zGetFolder is the name of the function that line of code is in. Does this zGetFolder only exist in the scope of the function?

Unfortunately I am not familiar with any languages with a "V" in name...

Function zGetFolder( sFolder )
On Error Resume Next
Set zGetFolder = oFso.GetFolder( sFolder )
If Err.Number <> 0 Then
Wscript.Echo "Error connecting to: " & sFolder & VBlf & "[" & Err.Number & "]" & Err.Description
Wscript.Quit Err.Number
End If
End Function

Questions: The line I don't understand is: Set zGetFolder = oFso.GetFolder(sFolder) Why would you "Set" a call to oFso.GetFolder with "zGetFolder" the name of the function you are currently in??? I am also not quite sure what "On Error Resume Next" accomplishes with this construct.

No problem. My only issue is that they keep asking the same question. "How do you block key presses". Thanks

I don't mind if it is posted by you.

Using Raw Input from C# to handle multiple keyboards[^]

I would like to add a message that stays at the top of the article comments. Is this possible? Thanks

The test acceptance criteria said that one hand clapping must sound like two hands clapping.

We are moving to Git where I work and this thread is not giving me any warm fuzzies.

You should ask yourself if you should be doing this. The reason I used this code was I had a windows service that logged into a DB2 database via an ODBC driver. They routinely changed their passwords and sometimes would forget to tell us. When we tried to login in after a password had been changed the ODBC driver would pop up (attempt to pop up) a dialog allowing you to enter the new password which of course never showed up as it didn't have permissions. We didn't realize any problem until the client called telling us that they hadn't received any new data. Anyways the following code worked for me. Reference System.Management

/// Start the service
protected override void OnStart(string[] args)
{
ServiceDesktopPermission();
}

/// Using Management Object services the option "Allow service to interact with desktop"
/// can be enabled. This gets unchecked/disabled each time a new install or update of the
/// service is performed.
static public void ServiceDesktopPermission()
{
try
{
ConnectionOptions coOptions = new ConnectionOptions();

coOptions.Impersonation = ImpersonationLevel.Impersonate;
	
// CIMV2 is a namespace that contains all of the core OS and hardware classes.
// CIM (Common Information Model) which is an industry standard for describing 
//        data about applications and devices so that administrators and software 
//        management programs can control applications and devices on different 
//        platforms in the same way, ensuring interoperability across a network. 
		    
ManagementScope mgmtScope = new ManagementScope(@"root\\CIMV2", coOptions);
	
mgmtScope.Connect();
	
ManagementObject wmiService;

wmiService = new ManagementObject("Win32\_Service.Name='" + "My Service Name" + "'");
	
ManagementBaseObject InParam = wmiService.GetMethodParameters("Change");
	
InParam\["DesktopInteract"\] = true;
	
wmiService.InvokeMethod("Change", InParam, null);
  }

catch(Exception ex)
{
//TODO: Log this error
}
}

You have assumed that I get the number as a decimal. I get all the values as a string and also their type. I also wanted to be able to default to "0.00 if no formatting was supplied as most client are fine with that format. 1. I parse to decimal as I get it as a string. 2. I default to 0.00 if no format is given 3. I apply the formatting 4. I remove the % if exists 5. I return it as a string since if will be written to a flat file. If the calling routine did the work and then I need this functionality some where else then I have to maintain multiple copies. Maintaining the code in a method allows me to for example default to 0.00 Besides at this point we are trying to impose our coding style on each other which is fruitless. I appreciate your ideas but you haven't raised any points that help me solve my problem any better.

The point is that the format specifier "000000%" multiplies by 100 and adds the percent sign. So, given 15.00 the result of applying the above format string yields 001500%. The percent sign is undesirable and needs to be striped out. So the method I mention always strips out the % if it exists as I will never need to send a percentage. So, I have accomplished my needs by still allowing standard formatting to be used. I could have created a custom format specifier "000000i", and then in my number processing method look for i and then use implied decimal formatting.

Yeah, I took that into consideration, the amounts are always even dollar amounts and always US currency. thanks

Your probaby right. However, I was trying to stick with the standard string formatting options. In the end as I noted above I did the following: I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.

The contrains aren't silly they are provided by the client. My problem comes in trying to make a tool generic enough to provide all clients with their needs. Again this method would work if all clients wanted to use an assumed decimal point. In the end I ended up using the format string "000000%" which multiplies by one hundred thus given me the assumed decimal place. Then in my ProcessNumber method I remove the "%" if it exists. The "%" will only exist if I am using the assumed decimal approach and I can still use standard formatting for all clients. Problem solved.

I didn't vote a one. I was given the choice of Yes or No was this answer helpful. I selected no. I didn't even realize I was voting I was just answering a yes or no question. Thanks I will look at your suggestion. BTW Your answer didn't have the Yes or No question.

That, can be done as well but then your adding code to the UI part of the tool that will be used by possibly one client on only one type of field. I know I am being picky. Currently an item that can be written to a flat file has the following options: Field: Length: 10 Type: (float, int, etc) Format: 0.00 Padding: Space Padding Side: Right Default Value: None If I were to add a new field Implied Decimal It would only apply to one type of all the types and therefore essentially a hack, in my opinion. I realize that if the client can't fix this on his end I may have to put in a hack, but I am trying to leave that as a last resort.

Yes, that works but not under the contraints I layed out in my question. The code doesn't know where the decimal is implied or not. If I used your solution it would be right if for this client as he wants an implied decimal but wrong for everyone who doesn't want an emplied decimal point. I am looking for a workaround to not have to pass in either the decimal is implied or not hense my question about how to solve this via applying a format.

I am senting data in a flat file to a client who is parsing the data using Cobol and he is asking me to format money with an implied decimal point padded to 6 charaters in length. For example given $15 dollars he wants me to send either 001500 or 1500 I am not sure which yet but the problem is the same either way. I have a generic tool that allows me to pick a field to send and also to provide the formating to apply. Here is the method I call each time a number needs to be formatted:

static public string ProcessNumber(string amount, string format)
{
decimal temp;

 bool results = decimal.TryParse(amount, out temp);

 if(results)
 {
     string localFormat = string.IsNullOrEmpty(format) ? "0.00" : format;
     string convertedValue = temp.ToString(localFormat);
     return convertedValue;
 }

 return amount;

}

Normally, for money I would use the "0.00" or "000.00" format specifier when yields 15.00 or 015.00 respectively. I don't want to have to treat this request as a one off and write special code if I don't have to. I can't assume in any given case that the decimal will or won't be implied. Is there a way to apply a format to yield a textual representation of a number with an implied decimal place?