|
implement keyDown event in your control and write your code there.
and where ever you are ebedding your control.create a explict handle for keyDown event for this control and link it with keyDown event which you have created in your control
sameer
|
|
|
|
|
sorry, that's not correct in this case.
|
|
|
|
|
Holding the key down and repeat rate is windows related. For example some users might disable this feature in their windows. Your control has nothing to do with it. All you have to do is handle the KeyDown event and implement scrolling for each stroke. When the user holds the arrow key down your program should receive multiple strokes, not just the first.
Regards ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
sorry, that's not correct in this case.
|
|
|
|
|
Why is that? I just made a small test:
1- Make any control that accepts focus
2- Make a ListBox for example
3- Handle the KeyDown event in the first control and in that handler call ListBox.Items.Add() for example and see if it will be repeated or not.
Regards
|
|
|
|
|
I found the snippet to handle an arrow key being repeated in a winform control.
The ProcessCmdKey method must be overriden to trap that key and the repeat message.
Normally the keypress event is the one that allows repeat keypresses by holding the key down. (This rate of repeat is controlled by the bios and the OS)
The keypress event does not trap the arrow keys.
protected override bool ProcessCmdKey(ref Message msg, Keys keyData)
{
const int WM_KEYDOWN = 256;
const int WM_CHAR = 258;
const int WM_KEYUP = 257;
const int WM_SYSKEYDOWN = 260;
const int WM_SYSKEYUP = 261;
if (FromHandle(msg.HWnd) == this)
{
switch (msg.Msg)
{
case WM_KEYDOWN:
switch (keyData)
{
case Keys.Down:
int tag = (int)msg.LParam;
bool repeat = (tag & (1 << 30)) != 0;
if (repeat == true)
System.Diagnostics.Debug.WriteLine("********************");
if (this.SelectedIndex + 1 >= this.menuItems.Count)
this.SelectedIndex = 0;
else
this.SelectedIndex++;
|
|
|
|
|
Some quote from the MSDN[^] site:
"The KeyPress event is not raised by noncharacter keys; however, the noncharacter keys do raise the KeyDown and KeyUp events." You should do Keydown's instead of ProcessCmdKey, that's what you are doing anyways...
bradsnobar wrote: switch (msg.Msg)
{
case WM_KEYDOWN:
Just do it on the .NET way.
bradsnobar wrote: switch (keyData)
{
case Keys.Down:
You could write your switch statement on OnKeyDown method:
private void yourcontrol_KeyDown(object sender, System.Windows.Forms.KeyEventArgs e)
{
switch(e.KeyCode)
{
case Key.Down:
...
}
...
}
Beside, embedding System const's in your code is not a nice thing to do. Microsoft could just change the values and your code will go to the outerspace.
ps.: Some words from MSDN[^]:
Notes to Inheritors When overriding the ProcessCmdKey method in a derived class, a control should return true to indicate that it has processed the key. For keys that are not processed by the control, the result of calling the base class's ProcessCmdKey method should be returned. Controls will seldom, if ever, need to override this method.
Diego Valdevino
|
|
|
|
|
planning to change out the sql statements i had in one of my application i developed but then my boss was wonderinf if there would be any security issue since persons would now have access to our sql statments by simply jus viewing the store procedures. and i was wondering if there was any way to prevent this
which leads me right back to wondering if i should jus make it be hard coded in the application
so basically my two questions are:
1. is there a way to protect my storeprocedures i thought of leting the server ask for the server account and this works in that the db's password protected but when i click to use windows authentication it allowed me to connect which makes me think that this can be used as a way of getting around me protecting the store procedure say any idea or i am way of on my approach
2. whats the difference in performance between hardcodding sql statems or using store procdures
Kenny Edmond
|
|
|
|
|
The difference in performance is typically large. Use the sql stored procedures instead.
If they can see your stored procs then they can see your data too. So which is more valuable? Probably your data.
This is a seperate problem that can be addressed with a good amount of security.
There are typically three layers of security...
IIS --> SQL --> Windows (File System)
Sometimes the SQL auth is integrated so SQL and file system are the same.
Your choice. But, I choose seperated for higher security, and integrated for ease of use.
|
|
|
|
|
1. From Books on line: "you are creating a stored procedure and you want to make sure that the procedure definition cannot be viewed by other users, you can use the WITH ENCRYPTION clause. The procedure definition is then stored in an unreadable form.
After a stored procedure is encrypted, its definition cannot be decrypted and cannot be viewed by anyone, including the owner of the stored procedure or the system administrator."
This is a rather extreme step to take, however. most hardcoded SQL statements can easily be viewed with a utility that dumps the strings tables in and executable, so IMO stored procs, even unencrypted, are no less secure than hard-coded sql statements.
To view your Stored procs, the user would satill need to be able to log in to the server, to view the strings in your exe, all that is needed is read access to the file...
2. As a general rule, stored procedures are more efficient since the excecution plan is precompiled.
|
|
|
|
|
Stored Procs are faster and you can secure them just like anything else in SQL. But another point is valid. It is much harder to do SQL injection attacks on a stored procedure.
|
|
|
|
|
OK - a lot of people here have stated that stored procs are faster than inline SQL, and indeed that was the case for quite a while. This is not always the case now.
One of the common misconceptions with Sql Server (version 7 onwards) is that it compiles stored procedures. Well - WRONG!!! It doesn't. What it does do, is cache execution plans for all queries that run through it (even ad-hoc ones). The algorithms that are behind this are very sophisticated and have gone through a lot of revisions/improvements by the Sql Server team.
Some SPs will be quicker than inline SQL, and some inline SQL will be quicker than SPs. Evaluate what works for you. Hint - dynamic SQL is generally faster inline than SP because you only send the result of the dynamic query generation to Sql Server, rather than having Sql Server try to dynamically populate parameters, etc.
Security.
Well, it is true that people can get at your stored procedures. But, this only applies to the level of security that you have applied to your DB. Look at using roles and authentication to lock down the database.
You can also lock down who can see your source code by implementing a robust security model for your organisation. Use a decent version control system to control who has access to the code. Limit the access on the directories where people check out/in the code to, so that only authorised users can gain access.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world."
Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that."
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
I need a simple software. I can develop it but I only know .NET (C# and VB.NET).
How I can write application for symbian 9.1?
If not what is name of symbian development IDE?
Thank you all
[C_O_D_3___4___N_U_L_L]
[C_O_D_3___4___N_U_L_L]
|
|
|
|
|
Code4Null wrote: Is it possible to write app. for symbian by VS2005 and C# or VB.NET?
Yes.
What is symbian?
led mike
|
|
|
|
|
Symbian is most popular Oprating system for many smartphones line Nokia (3250, e50,e70,3650 ....... )
|
|
|
|
|
No, The CLR/CLI have not been ported to symbian to my knowlege.
|
|
|
|
|
Code4Null wrote: Oprating system for many smartphones
Excellent! Then all you need is a .NET Runtime for the OS and you can develop in C#. You got one of those?
led mike
|
|
|
|
|
Well, you can port your C# code to symbian using a tool called AppForge. I haven't tested it myself, but it's quite famous and IIRC you can graba 30 days trial to test it.
If not then you'd have to use Symbian SDK in C++. Unfortunately it doesn't work on C#.
Regards ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Hi,
I want use this code to enter some data to data base
data base is an access data base
rec is an instancce of class include some string data member that you see in code
<br />
private OleDbConnection Conn = new OleDbConnection(<br />
@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=../../../db.mdb");<br />
private OleDbDataAdapter dataAdapter = new OleDbDataAdapter();<br />
Conn.Open();<br />
string cmdText = "INSERT INTO tbl1 (fname, lname, relative,tel, " +<br />
"mobile, b_tel, fax, email, adrs, www, job, user)" +<br />
" VALUES ( '" + <br />
rec.FirstName + "', '" +<br />
rec.LastName + "', '" +<br />
rec.Relative + "', '" +<br />
rec.Tel + "', '" +<br />
rec.Mobile + "', '" +<br />
rec.B_tel + "', '" +<br />
rec.Fax + "', '" +<br />
rec.Email + "', '" +<br />
rec.Adrs + "', '" +<br />
rec.WWW + "', '" +<br />
rec.JobTitle + "', '" +<br />
rec.user + "' )";<br />
<br />
dataAdapter.InsertCommand = new OleDbCommand(cmdText, Conn); <br />
dataAdapter.InsertCommand.ExecuteNonQuery();<br />
Conn.Close();
but in runTime this error occurs :
"Syntax error in INSERT INTO statment"
please help me.
---------------------
Areff Bahrami(KAVEH)
Areff.HB@Gmail.com
---------------------
|
|
|
|
|
Congratulations! That is some of the best looking string concatenation code I have seen in years! Too bad it has a bug in it so you have to crawl through it and find what typing mistake you made. If only there were better ways to execute database queries from code.... wait... 
"Alot of the people on this forum are incredibly stupid, thinking that the internet is real"
Score: 1.0 in the Soap Box
|
|
|
|
|
Had a similar issue with Access recently, and for unknown reasons, using double quotes would insert where singles wouldn't. Might try that.
Further, you might want to look into parameterized queries for a number of reasons. Easier to work with, much nicer to look at and edit, less prone to error, and much more secure.
string sql = "insert into tbl (Field1, Field2, Field3) values (@Field1, @Field2, @Field3)";
OleDbCommand cmd = Conn.CreateCommand();
cmd.CommandText = sql;
cmd.AddParameter(new OleDbParameter("@Field1", rec.Field1));
cmd.AddParameter(new OleDbParameter("@Field2", rec.Field2));
cmd.AddParameter(new OleDbParameter("@Field3", rec.Field3));
IDataReader idr = cmd.ExecuteReader();
|
|
|
|
|
The reply from BoneSoft is essentially the correct approach (use parameters),
but the example code he provided likely will onmly work with the SqlClient namespace rater than
the OledbClient variation.
For OledbClient, the parameters are signified by using ? placeholders rather than parameter names,
so the sql becomes
string sql = "insert into tbl (Field1, Field2, Field3) values ( ?, ?, ?)";
The rest is still correct, the OledbParameters still require a unique name in the constructor,
but the name is not used, so the parameters must be added in exactly the order they are used
in the sql query.
|
|
|
|
|
Huh, ya learn something every day. Guess I've been pretty successful avoiding OleDb. I just typed that in from thought, I figured somebody would find something wrong with it, just didn't expect that. I'll have to remember that.
Actually, I started typing SqlCommand and had to go back and change it all. 
|
|
|
|
|
OleDbParameter has the same constructors, like (string name, object value), how do you setup your parameters with OleDb then? Just give them any name if it just goes by order?
|
|
|
|
|
BoneSoft wrote: Just give them any name if it just goes by order?
Correct, as long as the names are unique, only order matters. Since the names are still keys in the collection, they need to be unique or you get the unexpected side effect of redefining a parameter...
Kinda sucks, but I guess it's a compatibility thing...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
