We are using a poorly designed Windows engineering application in our office that does not allow importing of model definition data (as most other applications do). We can spend literally 1.5 weeks pointing and clicking in the GUI adding nodes, elements, etc. I will call this poorly written application "X".
So, would it be possible to write a parent application (I code C, C# & know how to read Petzold/Win32 a bit) that essentially would fire up this application "X" and intercept and inject windows messages into it's loop, so say, I could automatically fill in winform fields, and at least see what messages are being passed around? That way I could possibly script part of the repetitive elements of the GUI.
Thanks for any potential leads and starting points.
-jdrago
Related
I want to be able to write a WPF application that only allows one instance of it, but if the user opens another instance, the first instance opens a window. So, I need
Single instance only WPF application
Inter-process communication between new instances and the original, which allows the new instances to tell the first one to open a window.
I would like to know if this is possible, and how to do it, because so far, Google hasn't been of much help. I have seen other questions ask this problem, but none have actually been of help (and a few have not been in vb.net, but have still not answered this problem). I would really like a proper example of how to do this, because even though I have been using vb.net for a while, this sort of stuff I have never encountered.
Single instance only WPF application
You can use a named Mutex to ensure only one instance is running, see “make single instance application” what does this do? (example given in VB.Net)
Inter-process communication between new instances and the original
There are a number of options here, including WCF, .Net Remoting and Named Pipes, see What is the best choice for .NET inter-process communication?
I'm kind of new to Windows Forms. The Windows Forms app I've created is the front-end to a component that does very time-consuming data transformation tasks. The data transformation task emits events which the form subscribes to.
When the form receives an event, it alters the text in a label and calls Refresh() for that label.
When I run the process from the form, it remains responsive and updates the label text for maybe a minute or so. After that, it simply freezes and Windows declares the process 'Unresponsive' until the data transformation is finished, at which time the form unfreezes and the label shows that the data transformation is complete (as expected).
I haven't put the data transformation onto a separate thread - is this the first thing I should try? Can events cross threads? If not, what else should I do?
Yes, threading is where you should be working. Multi threading in WinForms, depending on your version, can be tricky.
If you're using .NET 4.0 or higher, you could be using the Microsoft Task Parallel Library.
Otherwise, there is a good article, here, from C# Corner that covers threading in WinForms applications that I'd suggest as a starting point.
The BackgroundWorker is another option for simplifying threading in WinForms.
Here's the story: I've been working on putting together an app in VS10 using Windows Forms in C++. This is my first experience with winforms, although I have a fair amount of experience with C++ and have worked with MFC a bit. The program needs to aquire data input from a hardware measurement system and the backend for that is mostly worked out. What I've been a bit stuck on is how to easily work with displaying this data in forms with the DataGridView and Chart objects. I'd also like to be able to save various sets of data and the programs current settings to disk that can be easily recalled and displayed in the program at a later point.
The solution I've been attempting so far has been to create a DataSet object for a certain program instance which holds some DataTables for the data and current settings. This is easily saved and read to XML files using the DataSet methods, which is nice. The tricky part for me using this method has been trying to sync up the program's display data and settings in the DataGridViews and Charts. It seems like these controls are really meant to be designed through the GUI. Maybe I'm just a noob, but I couldn't figure out how to get the DataSet I designed to link with my Charts using the "Add Project data source" dialog, so instead I set up a bindingSource and then proceeded to set Chart settings manually in the code. That's been getting hairy pretty quickly.
What would you have done to implement this, and how would you advise proceeding? I'm sure there has to be a much simpler way of doing this.
I've used Microsoft Chart Controls to display data from hardware measurement systems before with good results.
We store our data separately in arrays and when we want to display something, just call the AddXY function on the items to add a point. Configuring the graph in the first place is more easily done in designer though. Have a look at the samples for more info.
in our corporate directory users can search for their coworkers. Results are then displayed in a table-like layout on a plain HTML page (the backend is PHP if that's any matter). The list is limited to 25 entries.
Now the request has come up to show the presence status from Microsoft Lync next to every entry in that list. Creating a tiny Silverlight application to represent the status of one single person is quite easy, placing it to the left of each name is also.
This way of doing it will of course result in up to 25 almost-identical Silverlight objects beeing created and then accessing the Lync client API.
Another way to do it would be to place the complete listing inside a (more complex) Silverlight application, so that there wouldn't be but one instance on the page. This would also cause quite some extra development work.
The question: Is it considered bad practice to create 25 instances of the same Silverlight object on one single web page?
Thanks for any input or opinion you can give,
Patrick
If you're using this in an internal corporate environment and getting the finished product out quickly is important then you're likely fine. Each Silverlight object will need to query the Lync status of each employee so that may be a deciding factor in terms of performance.
Alternatively, it wouldn't be all the difficult or labor intensive to create a simple single user control representing a single user's Lync status and then display all inside of a single Silverlight app.
What are my options for printing in Silverlight 3? Assume I have this awesome Silverlight application/control that creates a graphical display of some data. Now the user wants to print it.
I have considered a few options but I have yet to test any of these. Before I do that I would like to get some feedback on how it can be done.
Use the browser printing capabilites. In my experience this is does not provide a useful print, but perhaps with some interaction between the Silverlight host and the browser it can be done?
Use WriteableBitmap. The image can either be written locally, but this requires interaction from the user, or sent to the server where a suitable file (e.g. PDF file) can be generated and then sent back to the browser. Unfortunately you now get the overhead of sending the image twice across the network and increased complexity on the server side.
Send XAML back to the server that is then rendered in a WPF application running on the server. The result is the sent back to the client. I'm not sure if this is possible at all however, but if it is the network overhead is less than in option 2. Unfortunately, the complexity on the server side is even higher.
Wait for Silverlight 4?
One thing I have considered is that my awesome control probably will have a ScrollViewer at the highest level, but the user will want to print the entire content of the control, not just whatever is visible inside the bounds of the ScrollViewer. How can I handle this added complexity?
In all seriousness, I think your best option is to wait until Silverlight 4 if your client can wait that long. I've seen a good bit of buzz about SL 4 supporting printing on twitter, though it's not official. I'd wait until PDC in a few weeks and see if any Silverlight bits trickle out to support printing.
Take a look at SmartPrint for Silverlight 3: http://www.smartwebcontrols.com/SmartPrintDetails.aspx
TBH I wouldn't use any of those options:-
Printing from the browser. Fine if you are printing say a chart or something else that scales well on a single sheet of paper. Rubbish for anything else especially where you have scrolled content.
WriteableBitmap. I can't see a client-side only solution being acceptable to the user "Please save this and then print it" message. It could be made to work bouncing off the server but would be bad for bandwidth use (bandwidth is import right? because in a well-connect intranet you wouldn't using Silverlight?).
Sending XAML to server for rendering. Really awkward it would be WPF XAML not SL XAML, where and how would you do the binding, why send XAML at all, since the server needs to be pretty much clued in on this so why can't it hold the XAML needed as well. Or were you thinking of sending just pure XAML with all the data needed? Still its a lot of plumbing needed in the SL that isn't actually related to SL.
Use Silverlight 4, its possible that in the not to distant future this would be the correct no-brainer choice (personally I wouldn't hold my breath) but right now SL4 doesn't exist.
A 5th option
Place report generating code on the server and have the Silverlight app inform the server of the data set required (not necessarily posting the data merely the criteria needed to access the correct set). In my experience direct prints of GUIs aren't particularly satisfactory when the user really needs a good printed form of the data.
Its true that at times the user just wants to quickly get some offline access to a grid of data as it looks there and then. In that situation users often find an export to spreadsheet compatible file preferable to printing, which would be possible from SL.
Something akin to number two is pretty much your best bet and is what I've seen done for printing in most Silverlight apps so far.
You can have the app send content for printing back to the web server (i.e. a new handler or query string parameters to a printing page) and pop up another page for the user to print web content from, or you could allow the user to download a file and have them print that.
Sliverlight 3 does not support printing.
If you can wait for silverlight 4, they have given it "high priority"
If not use Writeablebitmap: http://www.andybeaulieu.com/Home/tabid/67/EntryID/161/Default.aspx