|
Luc Pattyn wrote: fully qualified class names
As well it should... 
|
|
|
|
|
If you don't see it on the form, it shouldn't be in the tool box.
|
|
|
|
|
Hey guys,
I've created an application which I want to install on a server (Windows Server 2008 R2). I want the setup to run unattended and since the setup is being started from a Windows Service I cannot have any GUI components. Thus in fact, I want a silent setup. The MSI is here already. Executing is from a command prompt with the /? parameter, gives me a dialog window with all possible parameters. If I choose the /silent parameter, the software is not installed. If I choose the /passive parameter (unattended) Windows Server 2008 shows me a security box 'Do you want to allow the following program from an unknown publisher to make changed to this computer'.
How can I create a MSI file which fully supports silent installs on Windows Server 2008 (and Windows 7) ?
Thanks guys,
Eduard
|
|
|
|
|
|
Yes I Know that, as you read my question, the problem is that when the setup is running in 'silent mode', my software is not installed. It seems you have to have some kind of GUI in order to accept the UAC message. My question is if there is any way to get the setup going with automatic acceptance of the UAC message or something.
I understand there is no way to get rid of the UAC message, but maybe there is some kind of parameter accepting the UAC message (/q /uac=accept or something)...
|
|
|
|
|
I have a windows forms application.
I have a while(1) loop, which runs a Update Database functionality every 30 seconds.
There is Sleep(30000) in while(1) to wait.
This runs in background process.
Someone suggested me to use Windows.Forms Timer, while someone told me to use Threading.Timer.
My another requirement is that, i need to stop this background thread as whole on some UI tasks, so that Update Database functionality is not invoked at such times.
I require the suggestions to achieve same.
Thank You.
|
|
|
|
|
If it's a Forms application, you could add a Windows.Forms timer with an interval of 30000 msec, and do the update in its "tick" event. You then wouldn't need the while loop or thread sleep, and you can disable the timer as needed, preventing the activity.
Is there a reason to do your update in a background thread?
|
|
|
|
|
The application is pre-made by some other organization. I have to increase performance by doing necessary code changes.
he necessity for separate thread arises of UI not getting disturbed while execution.
But, as i see there is worst performance in application.Adding to it, local database is sql compact edition.
|
|
|
|
|
Do not use a Sleep command. This is the coding equivalent of summoning up a demon, and should be avoided at all costs. You are trying to run something at a periodic interval, so a timer should be your first port of call. If, however, your call is to happen 30 seconds AFTER the completion of the last call, then you may want to look at an alternate mechanism (although stopping and starting the timer may suffice for you here).
|
|
|
|
|
Out of curiosity, Pete, what's wrong with using Sleep() on a background thread? Obviously you NEVER want to sleep the GUI (As that would make the application non-responsive), but I don't see any downside to sleeping a background thread.
|
|
|
|
|
What happens if you need to tell the background thread to finish, and it's just started a Sleep(30000000) ? A better mechanism is to do something like:
lock (SyncLock)
{
Monitor.Wait(SyncLock, 30000000);
} I shudder whenever I see Thread.Sleep in code because I just know that the pitfalls haven't been considered.
|
|
|
|
|
Never thought of doing it that way... *adds that to the mental arsenal*
Generally I use Thread.Sleep for background threads that are intended to go for the entire life of the application, so terminating the thread isn't much of an issue... Yeah, it drops with an exception when the system is shutting down, but by that point, it's irrelevant as long as I make sure there isn't anything that can't be randomly interrupted.
But yeah, never thought of using a pulse as a thread-killer...
if (Monitor.Wait(ThreadAbortLock, 30000)) return;
Time to take a look through my system... I know a couple spots where this method would be preferable.
|
|
|
|
|
I always use a System.Timers.Timer for my Windows Services.
|
|
|
|
|
your first concern should be: do I want those operations on the GUI thread, or anywhere but the GUI thread? Having it in a separate thread right now points to the latter. So a Windows.Forms.Timer would be wrong as that one ticks on the GUI thread, all other timers could be fine.
Of course, the operations not running on the GUI thread also means you need InvokeRequired/Invoke if your updated data needs to become visible on the GUI, and having multiple threads (or non-GUI timers) requires attention to synchronization.
A secondary concern could be how much control you need on the actual thread the operations will be running. A timer would tick on a ThreadPool thread, and you would have no say in its priority, nor would you be able to abort it, if you were so inclined; ditto for a BackgroundWorker. A regular thread (an instance of the Thread class) would offer you full control.
One final remark: a timer tends to set a target for periodicity, it is the time span between the beginning of two consecutive events; a Thread.Sleep() sets a gap, typically from the end of one action to the beginning of another. This difference most often is irrelevant, it may cause the actual period to be slightly larger.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
What's the different between 2 code below?
1-Form2 obj1=new Form2();
obj1.show();
2-Form2 obj2=new Form2();
obj2.showDialog();

|
|
|
|
|
One shows a dialog (i.e. a modal window), the other shows a modeless window.
|
|
|
|
|
Well, showdialog() causes the form to be show as a "dialog" (hence the name). That means that it will retain focus in your application: you will notice that you can't place the focus on the calling form while the dialog remains active/visible.
Make sense?
|
|
|
|
|
so you mean that with showdialog I can access the component in form2 like textbox?
what can I do with dialog?
|
|
|
|
|
You need to make an accessor to expose the items you need from the form. Here is an example: I created a project with two forms. Form1 (parent/main) contains a textbox and a button. Form2 (dialog) has a textbox and two buttons (OK and Cancel). In the properties of the buttons, I set the "DialogResult" to "OK" and "Cancel" respectively, then in Form2's properties, set the AcceptButton to the OK button, and the CancelButton to the Cancel button. From there, the code is simple:
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
Form2 frm = new Form2();
if (frm.ShowDialog() == DialogResult.Cancel) return;
textBox1.Text = frm.Value;
}
}
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
public string Value
{
get { return textBox1.Text; }
}
}
|
|
|
|
|
Thanks you realy help me. 
|
|
|
|
|
In obj2.show you can move form everywhere but in another case it can move in the parent form area. I guess.. 
|
|
|
|
|
freshonlineMax wrote: n obj2.show you can move form everywhere but in another case it can move in the parent form area. I guess..
You guess wrong.
The second example just shows a dialog box. There's no constraint in where it can be moved - the constraint is in how you can interact with the hosting application. As it's modal, processing on the primary thread halts in the calling code until it is dismissed.
|
|
|
|
|
As an addition to what others have told you, the Form object must be disposed later if you show it with ShowDialog method, so in this case it is much better to do this:
using (Form2 obj2 = new Form2())
{
obj2.ShowDialog();
}
|
|
|
|
|
An additional addition to the previous good answers...
ShowDialog returns a value of type DialogResult that enables you to determine the result of whatever that form was shown for - useful for custom message box type dialogs etc.
|
|
|
|
|
Yes Both are using for showing Form.
But Firt one is used for showing form as a normal form.
But Second One Is Used for Showing Form as a Dialog. You can not access Normally from Mouse or Keyboard.
First Case shows Non Immediate Value Required.
Second Shows Must Value Required.
Best Regard
If you can think then I Can.
|
|
|
|