|
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.
|
|
|
|
|
For one, you need to qualify the CreateParams type as I did in my code. There is ambiguity when you use CreateParams for both the property name and use it internally. This may be causing problems with the designer. You can always use the work-around I gave you too (after all, why do you need layered windows at design-time?). It's not uncommon for controls to draw differently at design-time than they do at runtime (take the grid being drawn on the control at design-time, for example).
Finally, I would recommend you create a base class, perhaps something like LayeredForm from which both FormA and FormB derive, unless you wanted FormB to look and act exactly like FormA (unless you plan on overriding a whole bunch of functionality and programmatically removing and adding controls). When you inherit a form, you don't just inherit the functionality - you inherit the UI (the UI is build, after all, from the code being inheritted).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I am writing an app that needs to receive multicast data. However, the amount of data being sent on a single multicast group is enormous and I do not have any control over the publishing side of the data. So what I'd like to do is to run multiple instances of the same app on a single, high power machine and assign each instance of the app a manageable segment of the total multicast feed to process. So for example run 4 apps and let each of them process only 1/4 of the total amount of data each.
But here is the problem, which I hope one of you will be able to help me solve. If I run multiple instances that all try to join the same multicast group on the same machine I get the following error:
System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted
This happens when the UdpClient object is being instantiated as follows:
udpClient = new UdpClient(portNumber);
The interesting thing is that I do not have this problem when I run an app that was built using Visual C++ and WinSock. It only happens with the .NET framework.
Does anyone have an answer to this other than "use 4 separate machines"?
Thanks
Robert
|
|
|
|
|
goodpilot wrote:
Does anyone have an answer to this other than "use 4 separate machines"?
Yes - don't use multiple processes. Multiple processes will not necessarily solve the problem and will most likely add to it. Each process has significant overhead: it's own process space, handles, thread queues, and in this case a separate instance of the CLR loaded. The common, "more correct" approach would be to use worker threads. You can either use the Thread class or the ThreadPool.QueueUserWorkItem (recommended; read about thread pools in the ThreadPool class documentation) to split the work. You could even make this configuration at launch time using the .config file for the application. This will use significantly less memory, cause the CPU to perform better in regard to your application (it's not switching to time-slice between multiple applications - on threads), and give you greater control...not to mention solve your problem (since one process is listening to the socket).
So, all data would be received by the UdpClient (it would anyway - you're just processing in chunks). Just chunk the data to one of N number of worker threads. This is actually how most socket servers work that you'll find any information about, and they can service hundreds or even thousands of connections.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
As usual you are a big help. I will looking thread pooling as a solution.
Thanks,
Robert
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
