Why are you looking in directories? You're supposed to be looking in the help files which - at least for the core that should include this stuff - is a required download. Click on Start->Programs->Microsoft Platform SDK Month Year and you'll see the help files. You don't need to build anything.
And "certified C compiler"? You do realize that VS.NET includes the C/C++ compiler - it's the same compiler that builds mixed mode and pure .NET assemblies when the /clr switch is used. The PSDK also includes the compiler and linker in the bin directory, as is the common place for binaries in SDKs and in *nix systems. Again, though, you don't need to build anything. Just look in help for information.
If you don't have all the right help files, click on the Update link in that directory and install all the relevent documentation.
I'm down a little program that shows image sequences and I'm having a hard time with error handling, i have an xml settings file that i first want to load and when that has loaded and only if it has been successfull do I want the program to continue so heres the code at it's current state.
but it doesn't seem to be picking up if the file really exists or not, and I usually get a nullrefrence exeption, so how's the best way to check if the file exists?
Well, typically this will work (i.e.; xmlSettings = "settings.xml";), however say you want to place the file two directories above the executing file path you could simply do: @"..\..\settings.xml". I have seen an instance where when using an open file dialog can cause the selected path (even though not related to your particular file) being appended as the path infront of "settings.xml" when you call the Load(..) method. You might check into something such as Application.ExecutablePath so that you know you are always getting the absolute path to your file.
Is there any way to draw someting on a panel, then draw something above it
and treat those layers separately?
I mean, I don't wanna redraw the first layer, when the second changes,
neither the second when the first does, because it may takes quiet much time...
I've searched about layers in msdn, but found nothing.
Tried to set the second panel's backcolor transparent, but
even in this case, it does cover the dynamic drawing on the first panel
You don't need different controls (not layers, that's a different matter) to paint different portions. All you need to do is paint the invalidated regions which are passed to you in the PaintEventArgs of the Paint event (for code handling other controls) or the OnPaint method (for controls extending a control to override). For some things, this isn't always possible or necessary (like for a button, very little needs to be repainted so the whole thing is typically repainted). Just use the PaintEventArgs.ClipRectangle to figure out which regions you need to repaint.
Currently, I'm fetching page IDs from an XML file.
I want to write code that does the following:
1- Add these IDs to an array? arraylist? some kind of list?
2- Start 5 threads that will access this list simultaneously and download a page from the internet (for example http://www.page.com?pageid=ID) provided that each page should be downloaded only once.
3- These pages are saved on disk.
What happens in case of a powercut? How can I know which page did I stop at?
Thank you very much.
"A good friend, is like a good book: the inside is better than the cover..."
1- Create a global variable to give the pages to download and create 5 other variables to specify which page a tread is currently downloading.
2- Each time a tread finishes to download a page, it increases the global variable by one and sets its own variable to the page it curently downloads.
5- Save on a file, all the 5 variables and the gloabal one. In the case of power goes down, you will simply resume the 5 pages and will continue with the gloabl variable.
a,b,c,d,e are the current location of download of all the treads.
g is the gloable variable,
1,2,3 ... 20 are pages to download.
Stuff in bold is already downloaded.
Thus you get: 12 3a 45 6b 5 7c 8910 11d 12e 13g 14 15
In the case If power goes down, will will simply have to download pages 3,6,7,11,12 and then to continue with pages 13+.
profoundwhispers wrote: What happens in case of a powercut?
What do you mean a "powercut"? If you mean loss of power, the only way you can know which threads didn't finish is to use a file to persist each thread's URL that they're working on and whether or not they've finished. This is common in many caching situations.
As far as using threads, using an array list isn't really necessary because you'll have to pass an index to each thread for them to determine which one to work on. Instead, read each ID from the XML file like you're doing and use asynchronous calls to download the file, like HttpWebRequest.BeginGetResponse. You'll pass an AsyncCallback that can write to that cache file I mentioned. If you track how many IDs you read and then keep a counter for how many times the callback was executed (be sure to use locking to increment the counter to make sure, for instance using the lock keyword) you can know which ID was last (by checking the IAsyncResult.AsyncState, which you would pass into HttpWebRequest.BeginGetResponse - this is used to pass custom data from the async call to the callback for cases such as this).
You could also devise a similar situation using the ThreadPool.QueueUserWorkItem, which also uses a delegate to start in a new thread and accepts a state object (which can be a single object of any type, including an array, list, or collection of other objects). The simple Thread class doesn't now allow such state variables and there is additional benefits to using a ThreadPool over simple threads. (See the SDK documentation for details.)
I would recommend asynchronous calls, though. The functionality is provided so you might as well use it. Also keep in mind that if you devise your own system using delegates, that the C# compilers (and probably others) automatically add asynchronous versions of the Delegate.Invoke function so you can use delegates asynchronously, too.
I need to have custom save/open file dialogs but
since the .NET ones are sealed it can't be inherited, neither can the FileDialog class from which they inherit. Does anyone know of a good approach to creating a custom dialog for this purpose? What I need is something as simple as an
additional textfield rightmost in the dialog.
I would really really(!!) want to use the functionality in the available controls. I have come up with two approaches, of which the second I really don't know how to do.. =)
either (1) create a new control which aggregates a SaveFileDialog control for some functionality (like opening the stream to file, etc.)
or (2) make it 2 separate windows that stay next to each other, and remove the window decoration.
any more suggestions? Has anyone done this? Please let me know if you think you can help.
I've been discussing this with some other developers - including some Microsoft developers in the forums - and there isn't a way without going to a LOT of work. Basically, you have to encapsulate the functionality of the GetOpenFileName and GetSaveFileName functions, as well as the OPENFILENAME struct. This is what the OpenFileDialog and the SafeFileDialog (which inherit most of the functionality from the FileDialog class) do.
The biggest problem is dealing with the dialog template you'd assign to the lpTmeplateName member of the OPENFILENAME structure. In Win32 this isn't too hard because you can use resources (stored in the .rsrc section of a PE (portable executable)). To have this managed is definitely NOT easy! The engineers I even talked to do mentioned something along the lines of "not having time" to do this for 1.0 (which, since it's still not in 1.1 and doesn't appear to be in 2.0 means, "it's too hard").
If you want this managed, there are ways of making a DLGTEMPLATE out of a dialog resource (namely, your Form or Control that will physically extend the open and safe file dialogs), but you have to worry about converting units from pixels to dlg units and a lot more. There was an example I found on the 'net but I don't remember where. Just google for it if you dare try this. You'll need to P/Invoke all that code used in the exmample, as well as things like the GetDeviceCaps to get the proper unit measurements.
My recommendation is to write a native DLL that does this instead. You can then encapsulate your own custom open or save file dialogs in a Component like Microsoft does. Just make sure you distribute this native DLL with your application, putting it in a location that can be resolved (like the current working directory or any directory in the PATH environment variable). I don't have a sample because this alternative doesn't really work for my company because we use an Internet-deployed (ala touchless deployment) app and try to avoid native resources at all costs. I found a way around using a different approach.
Ok thanks, great answer =)
I don't really mind doing it the native way it's
not gonna be a problem for me.. But I'm not really big on windows .dll programming. Do you have any hints / directions as how to do this 'the native way'? Any good links for tutorials or so?
Also I once found some kind of solution to this problem my combining multiple windows and make them look like just one. Since I only need to add a component rightmost in the dialog, this would be a possible solution for me... Any ideas as to how this can be done?
For an example of encapsulating a custom method and struct, use a decompiler like .NET Reflector[^] and see how the FileDialog and its derivative classes work. That's the best thing I can tell you.
You could just have a simple native function in a native DLL that you can call, passing parameters as necessary or use a struct like the OPENFILENAME struct, though you could cut down on the members needed for your implementation.
As for the other idea, neither the GetOpenFileName, GetSaveFileName, or the OPENFILENAME struct accept positional values. Since the FileDialogs merely use these functions and structs, it won't know either (nor does it have positional properties of its own). You'll have to get a HWND of the dialog instead, most likely using FindWindow, and you could try encapsulating this by extending the NativeWindow class (a managed wrapper for existing windows) and use AssignHandle, passing the HWND that you got from FindWindow. You could then figure out the position and track it with another window.
There might be an easier way to do this alternative, but this is just off the top of my head and without any research. You could search to see if an easier / better way exists.