Is it possible to limit the number of copies while printing in Silverlight 4? Perhaps the "number of copies" textbox in the Print dialog can be disabled somehow?
As far as I know, there is no way to control the number of copies when printing from Silverlight. But at the following URL you'll find a way to achieve a "controlled" printing operation from Silverlight, that is: a way to execute a printing operation from Silverlight having the user not allowed to interact with the "Print" dialog box, that will be "auto-confirmed". In that way, the printing operation is forced to happen to the default printer only and in one (and only one) printed copy; in order to print further copies, the user will need to invoke again the print feature (and the application will be able to log properly the fact).
http://www.codeproject.com/KB/silverlight/SilverlightSilentPrinting.aspx
Please note: it's a solution suitable only in specific scenarios (line of business applications, with control over the target client machine).
Related
I am in the process of making a simple image viewer in VB.NET. I want to be able to open an image with my application. How does VB.NET receive the URL of the file that the user is trying to open?
Seems simple but without knowing key terms, my Google searches are returning completely the wrong things!
You want to inspect the Environment.CommandLine Property
This property provides access to the program name and any arguments specified on the command line when the current process was started.
The program name can include path information, but is not required to do so. Use the GetCommandLineArgs method to retrieve the command-line information parsed and stored in an array of strings.
What i'm trying to do, is a simple program where i have 2 textboxes, and a button.(there is more but no need to say for resolving my problem)
When i write text in the 1st textbox and click the button, it will be written in the 2nd textbox. Everything is ok here.
Now, when i run this program more than once, i want the text to be written in the 2nd textbox of the others programs.
Sorry for the bad explaination i gave you before, hope it's better :)
OLD DESCRIPTION
i'm actually trying to make a program that works pretty much like a
messenger (basically 2 textboxes, 1 to send, 1 to view, and a button
to send) and i can't figure out how to link the program with itself
(copies). I want it to be able to read the textboxes contained
in the other copies and i don't want it to be 1 program with 2 forms,
but 1 single form, running severeal times (2 or more) How can i
do that? /!\ NOTE : It will be on a single computer, just like 2
forms!
I am assuming you are doing this in WinForms and only running one executable.
Sounds like you you want to create a single instance of a class that is shared between several forms. It should raise an event when the values change. After you create each instance of your form you pass in the class. In the form you would declare it With Events. When one form updates the class it would raise an event notifying the other forms to refresh themselves.
If you are familiar with WPF and MVVM this sort of design would be a little cleaner, but that takes some time to get up to speed on.
This design would not be appropriate if you want to run seperate applications and communicate between them.
You will have to do some kind of IPC, respectively remoting.
You could use:
anonymous pipes
named pipes
UDP
TCP
WCF (would be overkill IMHO)
windows messaging (would be the easiest way)
I'm trying to pass messages between a vba application (in powerpoint- during a slideshow) and a .net application I wrote.
The only method I could think of, is sending keystrokes.
However, this method causes the powerpoint to lose focus.
can you suggest a solution ?
If all happens on the same machine, the easiest way maybe is to let the PPT write its status into the registry from where the other application reads it out (GetSetting(), SaveSetting()).
If PTT and the other process run on different machines, you could think of writing out the status into a small text file which can be read out asynchronously.
Another way of (synchronous) communication between two processes/applications on different machines is to use sockets and send information across the network.
I found an interesting way of communication between vba and .net, without file system manipulation, sockets or external objects.
First, We register powerpoint evets, as such:
http://www.vbaexpress.com/kb/getarticle.php?kb_id=327
Second, We update the clipboard in VBA on the presentation-start event:
http://word.mvps.org/faqs/macrosvba/ManipulateClipboard.htm
Third, We use a clipboard a listener on .net:
How do I monitor clipboard content changes in C#?
Last, We restore the original clipboard value on presentation-end event
Hey Overflow, I have an application which serves as a user interface for a spartan/command line program.
I have the program running on a separate process, and my application monitors it to see if it is responding and how mush CPU it is utilising.
Now I have a list of files in my program (listbox) which are to be sent to the application, which happens fine. But I want to be able to read text from the com-line so as to determine when the first file has been processed.
Com-line says one of "selecting settings", "unsupported format" and "cannot be fixed".
What I want to be able to do is when it says one of these three things, remove item(0) in listbox1.
Is this possible?
I thought of programming an event which handles com_exe.print or something or other, if possible.
Read the standard output from the process.
MSDN Article
Theres an example of synchronous reading from the process in that article.
You might be able to do what you want using the AttachConsole API function as described here. However, maybe an easier alternative would be if you could pipe the output of the command line app to a text file and then your app could just parse the text file (assuming that the command line file wouldn't lock the file completely, I'm not sure about that).
If you don't know how to pipe the output, this page has quite a bit of information.
We have an unattended app w/o a user interface that is is periodically run.
It is a VB.NET app. Instead of it being developed as a service, or a formless Windows application, it was developed with a form and all the code was placed in the form_load logic, with an "END" statement as the last line of code to terminate the program.
Other than producing a program that uses unneeded Windows form resources, is there a compelling reason to send this code back for rework to be changed to put the start up logic in a MAIN sub of a BAS file?
If the program is to enter and exit the mix (as opposed to running continuously) is there any point in making it a service?
If the app is developed with a Form do I have to worry about a dialog box being presented that no one will respond to even if there are no MessageBox commands in the app?
I recall there used to be something in VB6 where you could check an app as running unattended, presumably to avoid dialogs.
I don't know whether there are conditions where this will not run.
However, if the code was delivered by someone you will work with going forward, I would look at this as an opportunity to help them understand best practices (which this is not), and to help them understand that you expect best-practice code to be delivered.
First of all, you don't need it to be run in a Form.
Forms are there for Presentation, so it should not be done there.
If you don't want to mess with converting the application a Service (not difficult, but not very easy neither), you shoud create a Console Application, and then, schedule it with Windows Task Scheduler.
This way, you create a Console Application, with a Main function, that does exactly what you need.
Anyway, the programmer could show windows, so there should not be any messagebox. Any communication should be done via Logging to: local files, windows events, database.
If you want more information on any of them, ask me.
If you don't want it to be a service, nothing says that it has to be a windows service. Scheduling it to run via the Task Scheduler or something similar is a valid option.
However, it does sound like the developer should have choose a "Console App" project, instead of a "Windows Forms" project to create this app.
Send it back. The application is bulkier and slower than it needs to be, although that won't be much of an issue. It is somewhat more likely to run out of resources. But the main reason: converting it to a console app is very easy.
If you don't prefer for the Console window to popup, simply do the following.
Create a new class "Program.vb", add a public shared Main() method, and move the "OnLoad" logic from the form to this method.
Next delete the form, and change the project start up object (Available in the project properties window) to use the Program.Main instead of the Form.
This will have the same effect, without the windows forms resources being used. You can then remove the references to System.Windows.Form and System.Drawing.