|
No, it's not. The message pump handler can't be bypassed, unfortunately, and it's behavior is to put up the usual message box you see for an "unhandled" exception.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Im am in the process of creating a small util app for my development. I am developing using NAnt and NUnit. I was tired of clicking on *.bat files to build the program every time (I have 8 different bat files for different purposes) so I wanted to create an application where I could set the parameters in a GUI and then build the program with a click of a button.
So the question is, how do I start one application from another? In this case I have a .NET windows forms application and want to start NAnt from it with a set of arguments?
|
|
|
|
|
Quite simply: see the System.Diagnostics.Process class:
Process.Start("build.bat", "/some command /line arguments");You can do more like redirect stdout, stderr, and stdin and perform a ShellExecuteEx on file types as well. See the class library documentation for the Process class in the .NET Framework SDK for more information.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks. That was exactly what I wanted. But I do have one problem. I cannot make the commandline arguments work correctly. I wanted to redirect the std out to a textbox I have. This is the code (basically copied from .Net documentation):
<br />
Process myProcess = new Process();<br />
ProcessStartInfo myProcessStartInfo = new ProcessStartInfo("nant", "-D:debug=" + debug + " -D:doc=" + doc + " -buildfile:serverbuild.build -defaultframework:net-1.1");<br />
myProcessStartInfo.UseShellExecute = false;<br />
myProcessStartInfo.RedirectStandardOutput = true;<br />
myProcess.StartInfo = myProcessStartInfo;<br />
<br />
StreamReader myStreamReader = myProcess.StandardOutput;<br />
string myString = myStreamReader.ReadLine();<br />
this.output.TB.Text += myString;<br />
myProcess.Close();
This code starts nant like it should and redirects the output to my textbox but it completely ignores the arguments. Any ideas what might be causing that?
|
|
|
|
|
It won't ignore those arguments, but your arguments may be incorrect. Take, for example, "-D:doc=" + doc + "...". If doc has any spaces it in, this will cause an error but you should see that in your output. This will cause nant to either exit in error or run with the doc symbol defined as the first word before a space in the doc variable.
I also noticed you're not calling Process.Start, though maybe an oversight when you pseudo-copied example code.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Yes. I have the start in the code I tested. The complete code looks like this:
Process myProcess = new Process();<br />
ProcessStartInfo myProcessStartInfo = new ProcessStartInfo("nant", "-D:debug=" + debug + " -D:doc=" + doc + " -buildfile:serverbuild.build -defaultframework:net-1.1");<br />
myProcessStartInfo.UseShellExecute = false;<br />
myProcessStartInfo.RedirectStandardOutput = true;<br />
myProcess.StartInfo = myProcessStartInfo;<br />
myProcess.Start();<br />
<br />
StreamReader myStreamReader = myProcess.StandardOutput;<br />
string myString = myStreamReader.ReadLine();<br />
this.output.TB.Text += myString;<br />
myProcess.Close();
When I ask the ProcessStartInfo to show me what the argument string looks like it prints this:
-D:debug=true -D:doc=false -buildfile:serverbuild.build -defaultframework:net-1.1
In the *.bat file I used before to build the application the complete line to build the application was this:
nant.exe -D:debug=true -D:doc=false -buildfile:serverbuild.build -defaultframework:net-1.1
So the argument string looks correct.
|
|
|
|
|
Then make sure you set the current working directory to the directory that has the .build file (or use the fully-qualified path). The current working directory is either the executing application's directory, or the directory you're in when you launch the application from the command-line. You can do this by setting the ProcessStartInfo.WorkingDirectory to the correct directory.
If this doesn't help, please include what the standard output reads after the process exits. Without details about the problem, it's difficult to help you; all I can do is offer suggestions without knowing more.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank you really much for trying to help me
I now noticed that the build process actually works. NAnt builds the application correctly, but it is the output that confuses me. I have redirected the output to a textbox. The textbox contains this after the application is run:
NAnt 0.84 (Build 0.84.1455.0; net-1.0.win32; release; 2003-12-26)
And thats all. So it works some way but not completely. For example it says "net-1.0" but I use 1.1, but the build works and builds with 1.1.
|
|
|
|
|
Obviously that's the version information for NAnt itself: Build 0.84.1455.0, built on .NET 1.0 in release mode on December 26th, 2003.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
But the output from the buildprocess doesnt work. Obviously it works to a certain extent since it shows that NAnt started but nothing more. Do you have any idea why that is?
|
|
|
|
|
Never mind. I figured it out. I switched the ReadLine() to a ReadToEnd().
|
|
|
|
|
Hello,
I cant seem to debug an SQL stored procedure using VS .Net's debugger.
I set breakpoints on the data adapters call to Fill and the stored procedures first line.
However, when I debug, the breakpoint in the stored procedure turns to a question mark and says "The breakpoint will not currently be hit. Unable to bind SQL breakpoint at this time. Object containing the breakpoint not loaded".
What am I doing wrong? I want to break on the Fill call, and then step into it.
Thanx for the help,
-Flack
|
|
|
|
|
On what line did you set your breakpoint? The Create Procedure? Make sure you put it on the the first line of code inside the procedure. Or better yet, test your SQL in the SQL Queary analyzer first and you won't have to set that kind of a breakpoint. Also, in your Project Properties, under Debugging (I Think!), make sure that you have SQL debugging enabled.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
The problem description goes like this...
person A is accessing a record to update, i want this record to be locked till the person A finishes his updation.
i want this to be implemented at BLL(Not IN database)
Regards,
|
|
|
|
|
The database is the best place to do it? Why would you want to do it anywhere else. You do understand that, unless you're using XML Web Services, .NET Remoting, or some other singleton that handles all user requests, there's no better way to do it and that every process has distinct resources?
In SQL Server, for example, you can use row-level locking while updating data like so:
UPDATE MyTable WITH ROWLOCK
SET SomeField = 'Some Value'
WHERE ID = 1 Without a daemon brokering calls to clients (which an RDBMS already is, so why write another?), there's no way to lock an object (row, table, etc.) for one particular user from others.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
You would pretty much need to use the database to do this. You could put a boolean column on your table that would indicate the row is locked. And you may want to make use of a timestamp column as well to ensure that when you update the row, that you know that you read the most current record before attempting that update.
|
|
|
|
|
I assume you mean that the person A has a record on his screen, and you want to lock it until he is done editing it. (If thats not what you mean, then check the preceeding comments for your answer).
That is known as "pessimistic concurrency", which is out of fashion, for good reason. The most common technique nowadays is "optimistic", whereby you assume that no-one else will change the record, but trigger an error if someone has. This is usually achieved through the use of timestamps on the records.
my blog
|
|
|
|
|
You could use COM+ via System.EnterpriseServices namespace if you want to achieve it. However, it's painfully slow if a lot of objects are involved, and some magic spells are required for your objects to become exposed to COM+ 
Also, you can create a lock manager singleton in your BLL that will be resposible for giving/refusing locks to objects in question.
Regards,
Serge (Logic Software, Easy Projects .NET site)
|
|
|
|
|
I have two problems:
First problem is that I'm trying to run two forms classes at time using Application context(basicaly copied code from SDK) and both forms give a taskbar button. I would like to just combine then into 1... since I might have several forms running at same time and don't want to fill up the task bar with buttons.
Second problem is that I created a class that is derived from System.Windows.Forms.Form and I've created another class that derives it, and I can't design it.
Basicaly:
class BaseForm : System.Windows.Forms.Form
{
Blah;
}
class NewForm : BaseForm
{
Blah;
}
Now I would like to design NewForm, but designer will not let me(if I change BaseForm to System.Windows.Forms.Form, then I can design, then change it back, but I don't like that as I will run into problems in the future).
Anyways, Thanks for any help...
J.S.
|
|
|
|
|
A task bar button can only represent 1 form, but the process is activated under normal circumstances so that when that form becomes active, all your process's forms become active. Just set one of the form's ShowInTaskbar properties to false and try it.
As for the second problem, while your code is correct the designer won't like it. The designer requires certain "elements" (methods, fields, etc.) to be present in the source file. To add an inheritted form that can be designed, compile your project with the first form (derived from Form), then right-click on the project and select Add->Add Inheritted Form. Pick the form you want to extend and click OK. You should now be able to design it.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
ok, when I set ShowInTaskbar to false, the form doesn't show up at all ;/ Thanks for getting the second problem to work.
|
|
|
|
|
If this is in your inheritted forms, they are not actually two forms but one. Are you actually displaying two distinct forms, or were you merely telling us that your derived form should be displayed? When you extend a class, that class inherits all functionality from its base classes.
If you have two distinct instances of a form, then only set one form's ShowInTaskbar property to false as I mentioned before. Do not set both.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
The problem stems from the fact that I am trying to use layered windows
The code:
protected override CreateParams CreateParams
{
get
{
CreateParams cp = base.CreateParams;
cp.ExStyle |= Win32.WS_EX_LAYERED;
return cp;
}
}
causes the designer not to work(get an error about the window handle) and also causes one of the forms not to show up. When I disable that line of code, everything works like its suppose to... well, except that my whole project is written around that. Not sure what I can do about the designer, except have "design time" code and run-time code... and then still have to figure out about the multiple taskbar icons thing(which I could work around, but introduces a lot more trouble).
Basicaly I'm displaying all my stuff to a bitmap, then displaying that using layered windows techniques... I'm totally confused about why that code would cause the problem with the ShowInTaskbar... I could possibly understand with the designer(but still think it should be able to handle it(atleast ignore it))... anyways, thanks for all the help...
|
|
|
|
|
You've really got me confused. You've gone from displaying two forms to inheritted forms to setting one property that affects two forms to layered windows. Please, be specific about what you're trying to do. I honestly have no idea of what you're trying to do at this point in time.
If that particular chunk of code isn't working in the designer, you can simply "skip" it while in design mode:
protected override System.Windows.Forms.CreateParams CreateParams
{
get
{
System.Windows.Forms.CreateParams cp = base.CreateParams;
if (!DesignMode)
cp.ExStyle |= Win32.WS_EX_LAYERED;
return cp;
}
}Sorry I can't say more, but like I said it's hard to figure out what you're trying to do with the seemingly different tracks you've gone down so far in this thread. Please ellaborate and I'm sure I or someone else can help.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
What I'm saying is, that because I am using layered windows(setting the WS_EX_LAYERED flag and using UpdateLayeredWindow WinAPI call to display form), I it is causing problems with the multiple forms and also the inherited forms.
If I used layered forms(setting the WS_EX_LAYERED flag), then when I do multiple forms, and set form2.ShowInTaskbar = false; form2 does not show up at all(but when I do not set WS_EX_LAYERED, it works like it suppose(taskbar icon does not show up, but for does). Also, if I set that flag and try to design an inheritted form, it gives me an error about creating a windows handle, again, it works if I don't use the WS_EX_LAYERED flag.
I have setup my code so I can say if I am going to use layering techniques or not, and this solves the designer problem. But I still have the taskbar problem... I want to use layering, but need for both forms to show up and only one taskbar icon.
Heres the code that will demonstrate part of the problem(just comment out the cp.ExStyle |= 0x00080000; to get the designer to work on FormB)
FormB.cs
using System;<br />
using System.Windows.Forms;<br />
<br />
public class FormB : FormA<br />
{<br />
public FormB() { }<br />
}
FormA.cs
using System;<br />
using System.Windows.Forms;<br />
<br />
public class FormA : System.Windows.Forms.Form<br />
{<br />
public FormA() { }<br />
<br />
protected override CreateParams CreateParams<br />
{<br />
get <br />
{<br />
CreateParams cp = base.CreateParams;<br />
cp.ExStyle |= 0x00080000; <br />
return cp;<br />
<br />
}<br />
}<br />
}
Test.cs
using System;<br />
using System.ComponentModel;<br />
using System.Windows.Forms;<br />
<br />
<br />
class MyApplicationContext : ApplicationContext <br />
{<br />
FormA form1;<br />
FormB form2;<br />
<br />
private MyApplicationContext() <br />
{<br />
<br />
<br />
Application.ApplicationExit += new EventHandler(this.OnApplicationExit);<br />
<br />
form1 = new FormA();<br />
form1.Closed += new EventHandler(OnFormClosed); <br />
form1.Closing += new CancelEventHandler(OnFormClosing); <br />
form1.Show();<br />
<br />
form2 = new FormB();<br />
form2.Closed += new EventHandler(OnFormClosed); <br />
form2.Closing += new CancelEventHandler(OnFormClosing); <br />
<br />
form2.ShowInTaskbar = false;<br />
form2.Show();<br />
<br />
<br />
<br />
<br />
}<br />
<br />
private void OnApplicationExit(object sender, EventArgs e) { }<br />
<br />
private void OnFormClosing(object sender, CancelEventArgs e) { }<br />
<br />
private void OnFormClosed(object sender, EventArgs e) { ExitThread(); }<br />
<br />
[STAThread]<br />
static void Main(string[] args) <br />
{<br />
MyApplicationContext context = new MyApplicationContext();<br />
Application.Run(context);<br />
}<br />
}
Now, if you test this, you will see that you get an error when trying to design FormB(but not FormA). You can't see the problem with the taskbar because to draw the forms I would need to include a lot more code(have to call UpdateLayeredWindow in the Win32 API). I'll mess around with that part of the problem and maybe can fix it.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
