Is the a method to programmatically open the "Windows Settings" form (in Windows 10) from vb.net, as though you did it from the Start Menu?

I am sending information between two vb.net applications using named pipes; serializing the information object, sending it to the second app, then deserializing it. All works well, but I am finding that I need to send more than one type of object. However, I cannot tell the type of serialized object that has been received until *after* it has been deserialized. Is there a method of identifying the object type *before* I deserialize it so I can then cast it into the proper object type when received?

I've created a Custom Control that inherits a PictureBox control. When a TestApp uses my newly created custom control, I'd like to add some additional data to the MouseMove event that is returned. Currently the raised event would appear in the TestApp as.... Private Sub MyCustomControl_MouseMove(sender as object, e as MouseEventArgs) handles MyCustomControl.MouseMove My first thought was to add additional arguments such as.... Private Sub MyCustomControl_MouseMove(sender as object, e as MouseEventArgs, MyExtraArgument as double) handles MyCustomControl.MouseMove or as an alternative, add my extra argument to the MouseEventArgs class so it would appear as... e.MyExtraArgument Is either of these methods possible? I'm under the impression that these events/objects may not be overridden without being able to modify the original source code of the parent control. Are there any simple examples of doing either of these techniques? Ideally I'd like to keep all the code within my newly created control library so that the TestApp doesn't require anything other than dropping the newly created child control into it.

Thanks, I'm aware that the math can be done manually. I was hoping for a third-party component so I could focus my efforts elsewhere and not have to focus on writing code for the existing drawing components.

I'm doing quite a bit of graphics work that involves displaying material on a cartesian coordinate graph using GDI+ methods (DrawLine, DrawRectangle, etc) in the Paint routines of a PictureBox. I'm always having to deal with scaling, rotation matrices and the other complications because the picturebox needs to have it's 'world' scaled rotated and translated before displaying normal Cartesian coords properly. Even with all this, it's always extra work to handle the fact that pens and some other graphics objects then draw their sizes transformed as well, and mouse events don't necessarily return points correctly. Many years ago, I used TrueBasic and it had a drawing component that you could set up as simple as giving the width, height and everything transformed accordingly. I'm looking for a dotnet component that will give me a similiar object so I can stop having to customize the existing picturebox. Paid components are fine, but I have to be able to use GDI+ to draw in it or it must support something similiar. I do *not* want to use graphing/charting components that require the graphics objects/points to be stored in their own arrays or other unique systems. I want to do the drawing myself. Any suggestions for a third party component?

While I appreciate the effort bojammis, It's more about understanding the issue and why the parent code compiles, or better yet, if it can be avoided with some IDE setting. There are a number of ways to avoid the problem, including using the DesignerMode flag to determine if code should run. Unfortunately it isn't only constructors that run. Load() and other events are triggered at undesired times as well, complicating the code, when the whole purpose of the inherited form should be for the simplification of the code. Also for clarification, my code does a lot more than build a timer--I simplified my description for this post. There are several independent background tasks which are being launched that now all have to monitor if the IDE is running them, or the designer.

I’m working on an application that uses an inherited windows form. I’ve accepted the forms designer bugs that accompany using inherited forms in Visual Studio 2012, but I’m trying to understand the nature of the inherited form itself. My original (parent) form code is relatively simple, but contains a small loop that updates a label control on the form with the current time. This form is then inherited by my other forms so that they will always display the current time. When I look at the parent form in the forms designer, it displays as it should, with whatever default text I’ve placed into the label control. However, when I look at any of my child/descendant forms their label is being updated with the current time, i.e. the code of the original parent form is compiled and running, even while viewing the descendant form in the VS Forms Designer. This seems strange to me—shouldn’t the descendant forms be inheriting the source code *only*, but not actually running it until the project is compiled and run?

A BackgroundWorker would give similiar function, but I have several more events that BGW supports. And although I probably could inherit a class using BGW, I'd really like to learn the methodology myself and incorporate it into my objects.

I written a ProcessUtility class that allows me to call a process (which in turn runs a commandline executable) asynchronously. The process then raises events indicating completion, progress, etc. When the ProcessUtility class is set up from the UI form as: dim WithEvents P as ProcessUtility_Class P.Start All runs as expected. Events are raised appropriately and, as expected, they are on a different thread from the UI and calls to the UI controls must be invoked to avoid cross-threading errors. I've been reading up on async, synchronization contexts and other threading concepts to better understand the issues. While I can (and have) wrapped every UI call within the events, it seems very redundant to have to do it every time a UI element is utilized. Since the problem isn't really the UI, but the Asynchronous process that is raising events in the "wrong" thread to the UI, it seems that there should be a (better) way to have my ProcessUtility class raise it's events within the threading context of the UI (if desired). That way, only the few events are specialized and whatever happens within them is UI-threadsafe. Perhaps something along the lines of (pseudocode): ProcessUtility_Class Public Event Process_Started(ThisProcess as sender, SecondArg as string) Public sub Start(Form1) Form1.StartInvoke 'Everything from here until endinvoke happens within the MyForm thread RaiseEvent Process_Started(blah, blah) Form1.EndInvoke DoStuffAsynchronously End Sub Is there something like this that can be done that the raised events are always running in the context of the main form that created the ProcessUtility_Class object in the first place? My goal is to avoid having to continuously wrap every UI call with delegates and invokes.

Thanks for the response, Alan. A quick check confirms what you stated--that the OutputDataReceived and ErrorDataReceived are raised with a Nothing value for e.data as the last call after returning their respective data. Since this call happens only once (for each Received event) and *only* after the data is completed, I can set a local flag within the process for each Received event when that happens. Between the two flags and the process.hasexited() property I can raise a custom event along the lines of: If Process.HasExited() and OutputDataReceived_IsCompleted and ErrorDataReceived_IsCompleted then Raise Event Process_HasTrulyCompleted() EndIf This seems to be the only guaranteed manner of knowing that all the conditions are met.

I've started a process that runs a command line executable and takes several seconds to return. I've attached/enabled events (OutputDataReceived and ErrorDataReceived) to enable the returning of STDOUT and STDERR messages from the process as they appear. All works fine, and all events return the lines of text as they should for stdout and stderr as they appear. But I've noticed that the OutputDataReceived and ErrorDataReceived events continue to be fired and return output *even after* the process.Exited() event has fired. I would have thought that the process had not yet completed until the last of Error and Output events have been caught/raised, but perhaps there is some kind of buffering going on within the Process that I am unaware of. If this is so, how can I know when the Process has *truly* completed-- as in the OUT and ERR data have fired for the last time *and* the process has truly exited? Ideally I would not read the contents of the OUT and ERR until the process is truly completed, therefore telling me that there is no output to follow the Exited() event.

I now have an alternative.....Dave, this may be similiar to what you are suggesting, although it does seem to work despite some of the issues you raised. Someone on another list suggested changing the apptype to Console App *after* the app has already been created. I didn't want to change the app drastically and get involved with the whole main/app.run stuff. Plus, I have several utility programs that can benefit from this. Apparently by creating the app normally (as a windows application) and using console.writeline to write to the IDE console for debugging can be the starting point. Afterwards, the app type can be changed (in the IDE Properties for the project) to Console Application. At this point, all the existing infrastructure still works, but console.writeline will now output to something other than the IDE console window. If the app is run from the IDE, it will automatically create a shell window and output to that. However, if the app is run from an existing shell, output will be sent to that window (as expected since this is the shell window that spawned the app) and the app runs as a gui-based application. The best of both worlds. The only bad side is that if the app is run from an icon, it will open a shell for it's output. This is acceptable for me since the app will always be run from an existing shell app. Thanks for the help Dave!

Hate to keep repeating it, but I cannot create the console: It needs to be an existing shell in which the user executes the gui app, then the string is returned to the (same) shell. It's like the event handlers injected into a gui app disable the "console-ness" of it.

I'll wait to respond until I've sure you've read the second response I made....I don't think I was being very clear previously. I'm pretty sure that my vb task should be able to respond to the parent shell window...just not sure how ;)

Upon rereading your post, a light went on in my head. You might be assuming that *I* am creating the console in which my code is running. The console is a standard DOS shell (cmd.exe) that is run by the user. *My Application*, while gui-based, is being run from that command shell as a commandline. I'm trying to get my app to print text to the shell from which it was called. In C, the closest thing would be a printf(). Hope that helps....

vb.net 2005. As for "code that created the console", I'm not sure of what you are asking: For testing, I'm creating a standard windows form application (hence as I mentioned it being gui-based and not console-based). Call it MyApp for discussion sake. Somewhere in the code (in this case within the Form_Load event) I have placed a console.writeline("hello world") statement. I was expecting this to display to the console when the program is run from a console, such as: c:\>MyApp and display hello world accordingly. However, nothing is ever displayed on the command line after the program quits. I'm guessing at this point that console.writeline doesn't really write to the console if the app is gui/form based, even if it is called from the command line....?

I have a simple vb.net gui application (an alternative file requester in a form) that I would like to run from the command line. It executes fine, but I find that I cannot send any output (a string representing the file selected) to the command line upon completion. It appears that "console.writeline" doesn't actually write to the console? Any suggestions as to how to send info back to the console window upon completion? Keep in mind that this is a gui app (not straight console).

Correct me if I'm wrong here, but wasn't one of the tenets of DotNet that--because dlls and "called components" could all be contained within an app's installation folder--that it cured DLL hell-type issues like this? If the installer gets the information on what to install from the app itself, and the installer works but copying all the listed references does not, then by association the installer is doing something *extra* that it is not being told by the app (or at least, the info isn't visible to the user). There has to be a manner of seeing this info so that I can manually copy those file independently and make sure they are there. Perhaps an app that can detect what refs are being called during an app's execution.....

Ah. That makes sense...Since both frameworks are installed, it should be safe to assume that the correct version is being used. No, nothing in the event logs (any of them). Just the before-mentioned error message/dialog. Ideally, I'd like to be able to "self enclose" my in-house apps in a folder, then to installations by copying this folder to machines on our network. I've done this in the past with 2003, and even place folders of apps on a linux server that users on windows boxes can run from their desktops. However, since switching to 2005 this seems a bit more unpredictable. There has to be a reliable method of guaranteeing that all references for an app are in a folder to be copied to to local machine *without* having to perform a full install. Someone on a newsgroup suggested ClickOnce, but this seems just as skittish, and only installs for the current user.

Dave, I'm not sure what you're saying here....is what you are describing that my new vb.net 2005 application (which uses framework 2.0) is trying to run using framework 1.0 and failing? Even though both frameworks 1.0 and 2.0 are *both* installed on the machine? Is it possible that I've compiled (in vb.net 2006) an app that is forcing itself to use the 1.0 framework by mistake? How would this be "deterred" if so?