|
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
|
|
|
|
|
Hello,
I am working with the TraceSwitch class and am having a problem.
First I created a TraceSwitch variable:
static TraceSwitch traceSwitch = new TraceSwitch("FactorialTrace","Trace the factorial application");
Then, in my button click method I have code such as:
if(traceSwitch.TraceVerbose)<br />
Debug.WriteLine("Inside the button click event handler");
Then, I added an App.config file to my project and wrote this to its contents:
<br />
<?xml version="1.0" encoding="utf-8" ?><br />
<configuration><br />
<system.diagnostics><br />
<switches><br />
<add name="FactorialTrace" value="4"/><br />
</switches><br />
</system.diagnostics><br />
</configuration><br />
Now, when I try to debug the app I get this error at the first line I am checking the level of trace output
The following line:
if(traceSwitch.TraceVerbose)<br />
Debug.WriteLine("Inside the button click event handler");<br />
Gives this error:
An unhandled exception of type 'System.Configuration.ConfigurationException' occurred in system.dll
Additional information: Unrecognized element
I cant find any errors in App.config or anywhere else. Does anyone have any suggestions?
Thanx for the help 
-Flack
|
|
|
|
|
Does it say what element anywhere in the exception message? One thing to check is the file encoding, and use Edit->Advanced->View Whitespace and make sure there's no stray Unicode elements that would be invalid whitespace and may be treated as an element.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks a lot for the quick reply!
I did as you suggested and discovered that one of the lines in App.config had a bunch of white spaces appended to the end of it.
I got rid of those spaces and everything works great.
Thanks for the help
-Flack
|
|
|
|
|
I have a C# installer class and I want to retrieve the ProductCode property within the code. How do I do that?
Thanks in advance.
|
|
|
|
|
I'm guess that you mean you added an assembly with an Installer class (attributed with the RunInstallerAttribute class) as a custom action within a Windows Installer package using VS.NET (or anything, really)?
If so, you have to pass it as a command-line parameter. In the Installer class, you can query command-line parameters easily using the Context.Parameters property. It's a simple dictionary. So, lets say you define a command-line parameter named "ProductCode", you'd access it like so:
public override void Install(IDictionary stateSaver)
{
string productCode = Context.Parameters["ProductCode"];
if (productCode != null)
{
}
}In the custom action command-line within the designer for the VS.NET distribution package (an MSI), add /ProductCode=[ProductCode] to the command-line. That will pass-in the ProductCode for the MSI as a command-line argument.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
|
I am writing some business classes and want to use an enumeration for one of the properties. I am not sure about how to organize the code. I was going to put the enumeration into a separate file:
namespace MyNamespace
{
using System;
public enum EnumDayType : int
{
Weekend= 1,
Holiday = 2
}
}
Then in my class file:
namespace MyNamespace
{
using System;
public class DayType
{
private EnumDayType dayType;
}
}
Is this the correct way to organize my code across files? What are some of the naming conventions for the enumerations (should I preceed the name with Enum, for example)? Should I have a separate source file for each enumeration? Any other suggestions? Thank you. 
|
|
|
|
|
It actually doesn't matter: there's no notion of source files when you compile (only in a PDB - programming database - which is used for debugging and is not typically generated for release builds).
Personally, I either define an enum in the class's source file that uses it if it's the only place where it's used, or have a file in my project just for enums used throughout the namespace for that project. You could use a separate source file, though; like I said, it really doesn't matter.
Use whatever organization makes sense to you, unless you're in a team environment; then the team must decide what works best for them.
The only real recommendations that the Visual Studio .NET and .NET Framework SDK docs assert is naming conventions. Read Design Guidelines for Class Library Developers[^] in the .NET Framework SDK for more information.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
