KermMartian wrote:
Interesting. I was curious how frequently the DownloadProgressChangedEvent fires, whether it's every byte, every relevant incoming packet, or some larger increment, but unfortunately I don't see much on that in the documentation.

I suspect the reason for that is that the WebClient is a helper class aimed at ease of use (for example, you can use it to download or upload files over HTTP or FTP without having to manually put together the protocol-specific requests). As such the exact behaviour of the event varies depending on what is going on underneath. See the note, for example of where the event doesn't quite work as you'd expect:
Quote:
A passive FTP file transfer will always show a progress percentage of zero, since the server did not send the file size. To show progress, you can change the FTP connection to active by overriding the GetWebRequest virtual method:

As such, if you want finer control over data transfer, use the lower-level classes and do more of the work yourself. If you want something quick and easy, use WebClient.
How would I create a .lnk shortcut file? A lot of websites have said to use the WshShellClass, but it doesn't seem to work anymore (Visual Studio says "Interop type 'IWshRuntimeLibrary.WshShellClass' cannot be embedded. Use the applicable interface instead.").

Edit: Also, Kerm, can I use the Doors CS logo as part of the icon for my program? Right now, the icon looks like this:
WshShell works well for me:


Code:
// Find the Type that corresponds to the registered COM object WScript.Shell.
var shellType = Type.GetTypeFromProgID("WScript.Shell");
if (shellType == null) throw new Exception("Type WScript.Shell not registered.");

// Create an instance of the WScript.Shell COM object.
// The dynamic type makes COM interop much easier as it lets the runtime perform dynamic dispatch for us
// without needing to manually dig out and invoke the relevant methods ourself.
dynamic wScriptShell = Activator.CreateInstance(shellType);

try {
               
    // Build a path to the shortcut (stick it on the desktop).
    var shortcutPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory), "C# Shortcut.lnk");

    // Create a shortcut instance. This returns a WshShortcut.
    dynamic shortcut = wScriptShell.CreateShortcut(shortcutPath);
    try {

        // Populate the shortcut's properties.
        shortcut.TargetPath = "notepad.exe";

        // Save the shortcut to create it.
        shortcut.Save();

    } finally {
        // Free the shortcut COM object.
        Marshal.FinalReleaseComObject(shortcut);
        shortcut = null;
    }


} finally {
    // Free the WScript.Shell COM object.
    Marshal.FinalReleaseComObject(wScriptShell);
    wScriptShell = null;
}


Bear in mind that this is obviously very Windows-centric. Smile
benryves wrote:
WshShell works well for me:


Code:
// Find the Type that corresponds to the registered COM object WScript.Shell.
var shellType = Type.GetTypeFromProgID("WScript.Shell");
if (shellType == null) throw new Exception("Type WScript.Shell not registered.");

// Create an instance of the WScript.Shell COM object.
// The dynamic type makes COM interop much easier as it lets the runtime perform dynamic dispatch for us
// without needing to manually dig out and invoke the relevant methods ourself.
dynamic wScriptShell = Activator.CreateInstance(shellType);

try {
               
    // Build a path to the shortcut (stick it on the desktop).
    var shortcutPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.DesktopDirectory), "C# Shortcut.lnk");

    // Create a shortcut instance. This returns a WshShortcut.
    dynamic shortcut = wScriptShell.CreateShortcut(shortcutPath);
    try {

        // Populate the shortcut's properties.
        shortcut.TargetPath = "notepad.exe";

        // Save the shortcut to create it.
        shortcut.Save();

    } finally {
        // Free the shortcut COM object.
        Marshal.FinalReleaseComObject(shortcut);
        shortcut = null;
    }


} finally {
    // Free the WScript.Shell COM object.
    Marshal.FinalReleaseComObject(wScriptShell);
    wScriptShell = null;
}


Bear in mind that this is obviously very Windows-centric. Smile

Thank you so much, Benryves! I have one question, though, how would I set the icon to be displayed in the shortcut?
The icon can be set with the WshShortcut.IconLocation property, e.g:

Code:
shortcut.IconLocation = "imageres.dll,9";
Souvik, sounds good, enjoy the logo. I'm not sure that the wrench is placed precisely where I would have put it, but it's not my program. Wink
KermMartian wrote:
Souvik, sounds good, enjoy the logo. I'm not sure that the wrench is placed precisely where I would have put it, but it's not my program. Wink

Yeah, the wrench looks a little.. off.. to me too. I'll change that tomorrow, it was meant to be a rough draft.
souvik1997 wrote:
KermMartian wrote:
Souvik, sounds good, enjoy the logo. I'm not sure that the wrench is placed precisely where I would have put it, but it's not my program. Wink

Yeah, the wrench looks a little.. off.. to me too. I'll change that tomorrow, it was meant to be a rough draft.
No problem, that's more or less what I assumed. Smile It's a great concept regardless; I look forward to how you evolve it.
I tried my program on my mom's laptop (which runs XP), and I saw that Directory.GetCurrentDirectory()would return different values depending on which file the user picked. For example, if the user chose test.asm in My Documents, Directory.GetCurrentDirectory() would return My Documents. This only happened under Windows XP, but I've worked around it in my program.
Directory.GetCurrentDirectory() returns the current working directory, regardless of which version of Windows you're using. What did you expect it to return? One common mistake seems to be the assumption that the current working directory is the one that the executable is in (which it often isn't). To find the directory the executable is in use the Application.StartupPath property.
benryves wrote:
Directory.GetCurrentDirectory() returns the current working directory, regardless of which version of Windows you're using. What did you expect it to return? One common mistake seems to be the assumption that the current working directory is the one that the executable is in (which it often isn't). To find the directory the executable is in use the Application.StartupPath property.

For my shortcut, if I had used Application.StartupPath it would return the location of the shortcut, not the actual executable. I stored the location where the user chose to install the SDK in %appdata%\dcssdk\settings.txt, and I used Directory.SetCurrentDirectory() to change the current directory. Under Windows XP, Directory.GetCurrentDirectory() would return a different directory than what I set previously; it would return the directory of the file that was chosen to be assembled.

Edit: http://stackoverflow.com/questions/3018970/why-the-current-working-directory-changes-when-use-the-open-file-dialog-in-windo
souvik1997 wrote:
For my shortcut, if I had used Application.StartupPath it would return the location of the shortcut, not the actual executable.
I'm not sure what you mean by that, sorry.
Quote:
I stored the location where the user chose to install the SDK in %appdata%\dcssdk\settings.txt, and I used Directory.SetCurrentDirectory() to change the current directory. Under Windows XP, Directory.GetCurrentDirectory() would return a different directory than what I set previously; it would return the directory of the file that was chosen to be assembled.
Why do you need to set the working directory? When running the assembler process you should set the working directory for that process using the ProcessStartInfo.WorkingDirectory property.

I'm probably just not understanding what you're doing. Sad

For what it's worth, .NET has a built in settings system to avoid having to write your own implementation.
benryves wrote:
souvik1997 wrote:
For my shortcut, if I had used Application.StartupPath it would return the location of the shortcut, not the actual executable.
I'm not sure what you mean by that, sorry.

If I double-clicked on the shortcut to my program from my desktop, Application.StartupPath would return C:\Users\souvik1997\Desktop, not the directory where DCSSDK.exe is.
Quote:

Quote:
I stored the location where the user chose to install the SDK in %appdata%\dcssdk\settings.txt, and I used Directory.SetCurrentDirectory() to change the current directory. Under Windows XP, Directory.GetCurrentDirectory() would return a different directory than what I set previously; it would return the directory of the file that was chosen to be assembled.
Why do you need to set the working directory? When running the assembler process you should set the working directory for that process using the ProcessStartInfo.WorkingDirectory property.

I'm probably just not understanding what you're doing. Sad

For what it's worth, .NET has a built in settings system to avoid having to write your own implementation.

I suppose I don't really need to set the working directory, but it makes my code cleaner and I don't have to type as much. I set the current working directory so I don't have to append variables to the start of all my paths.
souvik1997 wrote:
benryves wrote:
souvik1997 wrote:
For my shortcut, if I had used Application.StartupPath it would return the location of the shortcut, not the actual executable.
I'm not sure what you mean by that, sorry.

If I double-clicked on the shortcut to my program from my desktop, Application.StartupPath would return C:\Users\souvik1997\Desktop, not the directory where DCSSDK.exe is.

Hrm, it shouldn't, but it seems there might be a bug with certain file dialogs. A more robust method (which works without WinForms, e.g. in a console application) could be to add your own implementation, which would be something like this:

Code:
static string StartupPath {
    get {
        return Path.GetDirectoryName(Assembly.GetExecutingAssembly().ManifestModule.FullyQualifiedName);
    }
}
New version!
DCSSDK.exe
Ionic.Zip.dll
This version can create desktop shortcuts, and contains numerous bug fixes.

Also, I'm having some problems with ILMerge:

Code:
C:\Users\souvik1997\Documents\Visual Studio 2010\Projects\WindowsFormsApplication1\WindowsFormsAppli
cation1\bin\Debug>ILMerge.exe /target:exe /out:selfcontained.exe DCSSDK.exe Ionic.Zip.dll
An exception occurred during merging:
Unresolved assembly reference not allowed: Microsoft.CSharp.
   at System.Compiler.Ir2md.GetAssemblyRefIndex(AssemblyNode assembly)
   at System.Compiler.Ir2md.GetTypeRefIndex(TypeNode type)
   at System.Compiler.Ir2md.GetTypeToken(TypeNode type)
   at System.Compiler.Ir2md.VisitConstructArray(ConstructArray consArr)
   at System.Compiler.Ir2md.VisitAssignmentStatement(AssignmentStatement assignment)
   at System.Compiler.Ir2md.VisitBlock(Block block)
   at System.Compiler.Ir2md.VisitBlock(Block block)
   at System.Compiler.Ir2md.VisitMethodBody(Method method)
   at System.Compiler.Ir2md.VisitMethod(Method method)
   at System.Compiler.Ir2md.VisitClass(Class Class)
   at System.Compiler.Ir2md.VisitModule(Module module)
   at System.Compiler.Ir2md.SetupMetadataWriter(String debugSymbolsLocation)
   at System.Compiler.Ir2md.WritePE(Module module, String debugSymbolsLocation, BinaryWriter writer)

   at System.Compiler.Writer.WritePE(String location, Boolean writeDebugSymbols, Module module, Bool
ean delaySign, String keyFileName, String keyName)
   at System.Compiler.Writer.WritePE(CompilerParameters compilerParameters, Module module)
   at ILMerging.ILMerge.Merge()
   at ILMerging.ILMerge.Main(String[] args)
Microsoft.CSharp is a .NET 4.0 feature - add the /v4 switch to ILMerge's command-line.
Here's a new version of the SDK GUI: Download
Please post any bugs you find in this topic, I will try to fix them as soon as I can.
I think this version should be stable on Windows 7 and Vista, but I'm running into a few problems under XP. If you have XP, and something doesn't work, please post here so I can (hopefully) fix it.
Download


Very cool! May I make a few suggestions?

1) A nice big "I already have the SDK, it's in this folder..." button on the first screen.
2) A text input box with the address of the SDK download, so that if for some reason it changes, the user can change the URL being used. Although I don't love this suggestion.

Comments: I love it so far! I think the option to download the SDK and to grab WabbitEmu is excellent.
KermMartian wrote:
Very cool! May I make a few suggestions?

1) A nice big "I already have the SDK, it's in this folder..." button on the first screen.
2) A text input box with the address of the SDK download, so that if for some reason it changes, the user can change the URL being used. Although I don't love this suggestion.

Comments: I love it so far! I think the option to download the SDK and to grab WabbitEmu is excellent.

For (1), do you mean something like this?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 4
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement