|
As default a service runs under the 'Local System' account. This account is restricted for security reasons.
Using the Services snapin for the MMC you can change the account the services runs under which should allow you more control.
|
|
|
|
|
Hi, originSH.
Thank for reply.
I have changed the account the services runs to my account (Administrator). but no luck.
goblins
|
|
|
|
|
First, the quota service has to be turned on. Then, by deault, there are no quotas. They have to be setup first.
|
|
|
|
|
Hi, Dave.
I set up the quota service in the first place. there are entries, Bob, Alice, Administrators, LOCAL SERVICE, etc.
Thanks.
|
|
|
|
|
Hi,
I have a MDI app. On one of the forms I have a control, that uses Ctrl + Shift + F4 and Ctrl + Shift + F6 as a shortcut. The problem is, that the control never gets the keys, because they are used for closing the form and switching MDI forms. Is there a way to disable this function, so they get to the control?
Thanks for reading ...
|
|
|
|
|
Have a look at Control.IsInputKey
|
|
|
|
|
Thanks for directions, but doesn't work
|
|
|
|
|
Don't override functions that are standard within the OS and that people are used to. It's really annoying. People won't want to use an app that doesn't behave in ways that they are expecting.
|
|
|
|
|
I'd really love to, cause I don't like it too. But this seems to me like a bug. If it was just Ctrl + F6, I won't say a thing and would choose another shortcut. But why Ctrl + Shift + F6 is handled like Ctrl + F6?
|
|
|
|
|
I have finally come to a solution. As you know, I think about this issue as a bug. The solution lefts the possibility to use Ctrl + F6 and Ctrl + F4 shortcuts as they are used throughout Windows environment (switching tabs and closing tabs in MDI apps):
    protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
    {
        if (keyData == (Keys.F4 | Keys.Shift | Keys.Control))
          return false;
        if (keyData == (Keys.F6 | Keys.Shift | Keys.Control))
          return false;
        return base.ProcessCmdKey(ref msg, keyData);
    }
Ondra
|
|
|
|
|
MrAndrew wrote: Disabling Ctrl + F4
I hate such applications which go against native Windows experiences. My first preference towards them would be navigating to Control Panel -> Add Remove and Uninstall.
|
|
|
|
|
As I stated, I think it's a bug in handling this keypress by .NET framework. It considers Ctrl + Shift + F4 as Ctrl + F4, which is wrong. My solution preserves the standard function of those keys ...
|
|
|
|
|
Hi all,
currently i am working on visual sutdio 2003 with .net framework 1.1,2
now i am thinking to move to .net framework 3 and visual studio 2005
does this affect my application should i do any special changes except of the installation ?
does upgrading my solution on VS 2003 to VS 2005 affect any thing other than the solution itself ?
kindly tell me about any effects that could happen due to this movement .
thanks
|
|
|
|
|
You shouldn't have any problems, except perhaps if you upgrade an existing ASP.NET app. Nothing should be insurmountable though.
Kevin
|
|
|
|
|
hi,
i want to upgrade an exsiting ASP.NET application . from VS2003 to VS2005
and the .net framework to version 3
so what do u mean by
You shouldn't have any problems, except perhaps if you upgrade an existing ASP.NET app
thanks
|
|
|
|
|
ASP.NET 2.0 is laid out very differently to 1.1
Christian Graus - Microsoft MVP - C++
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
|
Is there an easy way to assign a name to an already existing DataSet? I have code which I should not change that returns unnamed datasets, and these I add to a DataSet. The data binding scenario I'm using requires me to give names of DataTables in the DataSet. The Name property is read only on a DataTable.
|
|
|
|
|
Brady Kelly wrote: The Name property is read only on a DataTable.
DataTables don't have a Name property, and TableName isn't read only. What am I missing?
|
|
|
|
|
It's what I was missing, thanks.
|
|
|
|
|
Yes they do. Well, kind of. When you create a new DataTable object, you have the option of giving it name, but only in the constructor of the DT.
DataTable dt = new DataTable("Customers");
There is no Name property, but there is. If the DT is added to a DataSet's Tables collection, you can get at the table by index using the table name, or index number.
DataSet customerOrders = new DataSet();
customerOrders.Add(customers);
DataTable c = customerOrders.Tables["Customers"];
|
|
|
|
|
Is that different from .TableName ?
|
|
|
|
|
Oh my God! I feel like an idiot!:->
So much for consistancy using the Name property through out the BCL!
|
|
|
|
|
My apologies, I meant; "Is that not the value that is accessed by the .TableName property?"
But, yes, increased consistency would be good.
|
|
|
|
|
Yep, it is.
|
|
|
|