|
Please do not post this in multiple places: here and Q&A. All that does is duplicate work and annoy people.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Hi
I'm writing an outlook addin in VisuaStudio 2008 using the buildin Outlook addin project template of VS2008.
In my code I added a new button to one of the ActiveExplorer() commandbars.
I made it changed according to the number of items selected in the ActiveExplorer
using Application.ActiveExplorer().SelectionChange event.
this works just fine up until I click on the button and load my winForm. after doing so it seems like the Application events that I used (including : SelectionChange and ItemContextMenuDisplay) stopped triggered. and the button as a result stopped changing according to the number of items selected.
The winform is empty and loads up as ShowDialog.
Any ideas why and how to fix it? tnx leeoz
here is part of the relevant code (I only missed out the AddMenuBar(), ThisAddIn_Shutdown() and the other events which have the same problem after showing this winForm):
private void InternalStartup()
{
this.Application.ItemContextMenuDisplay +=new Microsoft.Office.Interop.Outlook.ApplicationEvents_11_ItemContextMenuDisplayEventHandler(Application_ItemContextMenuDisplay);
this.Application.ContextMenuClose +=new Microsoft.Office.Interop.Outlook.ApplicationEvents_11_ContextMenuCloseEventHandler(Application_ContextMenuClose);
this.Application.ActiveExplorer().SelectionChange += new Microsoft.Office.Interop.Outlook.ExplorerEvents_10_SelectionChangeEventHandler(ThisAddIn_SelectionChange);
this.Startup += new System.EventHandler(ThisAddIn_Startup);
this.Shutdown += new System.EventHandler(ThisAddIn_Shutdown);
}
void ThisAddIn_SelectionChange()
{
if (btnManualFiling != null)
{
if (this.Application.ActiveExplorer().Selection.Count > 0)
{
btnManualFiling.Enabled = true;
}
else
{
btnManualFiling.Enabled = false;
}
CurrentSelection = this.Application.ActiveExplorer().Selection.Count.ToString();
btnManualFiling.Caption = TomaxManCaption + "(" + CurrentSelection + " items)";
}
}
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
AddMenuBar();
}
private void buttonOne_Click(Office.CommandBarButton ctrl, ref bool cancel)
{
frmManualFiling wnd = new frmManualFiling(this.Application);
wnd.ShowDialog();
wnd.Dispose();
wnd = null;
}
|
|
|
|
|
|
So I have read this and know all of this before...
Still no answer to my question.
I understand that while the dialog is open the owner is puaused untill I close the dialog.
But my problem is after I close the dialog, the addin is still running ok, but all the events I've added from the beggining stopped from firing (i.e. while I change my selection I don't get the event to fire again).
Why and how to fix this, I don't know...?!
tnx
|
|
|
|
|
Ok, I missunderstood your first post.
Have you manually modified the InternalStartup method implementation to add the other event handlers? You shouldn't. It is better to place that into your Startup event handler.
Anyway, I have made a little plugin to test and get the same problem as you. I will try to find out what is going on and will tell you if I find something.
modified on Tuesday, October 26, 2010 11:02 AM
|
|
|
|
|
Ok, I can tell you how to fix it, though I can't tell you why, and after so many years fighting against MS-Outlook API, I have learned to yield in some cases and just look for a good work around.
Instead of this line you have:
Application.ActiveExplorer().SelectionChange += new Microsoft.Office.Interop.Outlook.ExplorerEvents_10_SelectionChangeEventHandler(ThisAddIn_SelectionChange);
Use a class level field to hold the explorer, and then set the event handler on it:
Microsoft.Office.Interop.Outlook.Explorer exp;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
exp = Application.ActiveExplorer();
exp.SelectionChange += new Microsoft.Office.Interop.Outlook.ExplorerEvents_10_SelectionChangeEventHandler(ThisAddIn_SelectionChange);
...
}
It works this way... Don't ask me why... I just don't even want to know.
|
|
|
|
|
tnx.
BTW should I do the same for Application.ItemContextMenuDisplay event?
i.e.
private this.Application app;
..
{
app.ItemContextMenuDisplay += new...
}
???
|
|
|
|
|
Dear friends,
This is head ache for me to handle this.
i got one link to overcome this issue.. which is given below
http://wiki.asp.net/page.aspx/1137/preventing-multiple-button-clicks/
its really grate but this is making issue for me
my submit button is asp button which have Validation Group = 'Transfer'
i have multiple text box on form which is handle dynamic when there is one scenario it is add Validation Group as 'Transfer' and remaining as 'NA' and vice versa.
issue is create when this submit button click it is validate the page at this time it is validate each and every control even that control is having Validation group as 'NA'.
Can any one help me to overcome this issue.
Sasmi
|
|
|
|
|
|
i have a project in c# code and 3 leyer; and all of data base code are in data leyer, which method is better?
1- send sql string statementto data base for select or update?
2 - using stored procedure?
in databases with larg scale wich is better?
pleas help me?!
|
|
|
|
|
Stored procedures are better than using SQL statements in your code.
sa.alavifar wrote: in databases with larg scale wich is better?
Depends on what are your options. SQL and Oracle are two from which you can choose.
|
|
|
|
|
Using a stored procedure is generally considered better. The SQL Server can create an execution plan which speeds the execution up. You also get built in protection against SQL injection attacks.
Whatever you do don't use an SQL string statement like this (without parameters):
string sql = "Select * from Table where name = " + idTextBox.Text;
as a hacker can type in SQL to the text box idTextBox and manipulate your DB, this is called SQL injection. Because Stored Procedures use parameters anyway, they are protected against this.
Finally, I'd suggest looking at the following: LinqToSql, The Entity Framework, NHibernate. These map C# objects to relational databases, you will find that this removes the need for a lot of boilerplate code. It looks like you have a new development, so using these technologies will probably be better, but YMMV.
|
|
|
|
|
<br />
string sql = "Select * from Table where name = " + idTextBox.Text;<br />
when i have an update, i was using the parameter that they are protected against SQL injection
i asked this question for example initial datagrid view in form laod,
so what is your idea?
|
|
|
|
|
This is still wide open to a SQL Injection attack. Just because it's a select statement, doesn't stop it from having a SQL Injection attack attached to it.
|
|
|
|
|
Try this:
idTextBox.Text = "Jones;DROP TABLE Table";
string sql = "Select * from Table where name = " + idTextBox.Text; Or better still, don't try it - just think about it. Can the user type that into idTextBox? Oh yes! And what happens to your database? 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I have a confession to make, sometimes I open your profile just to see the picture 
|
|
|
|
|
I'm not sure whether to be flattered that you like it, or disturbed that you felt a need to say it! 
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
That's exactly the effect I was looking for
|
|
|
|
|
Glad to have been of assistance then!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
0) I haven't written a stored procedure since I started using ADO.net. Before that, with ODBC, I had to write stored procedures in order to have transactions -- that was the only reason we used stored procedures.
1) Stored procedures are not inherently faster than SQL in code.[^]
2) Stored procedures offer some benefits, but I doubt most people capitalize on them (I wouldn't).
3) If you use stored procedures, you still need to have SQL (EXEC statements basically) in code anyway.
4) Most people write stored procedures simply because someone else said they should, not because they know what they're doing.
5) A properly-developed Data Access Layer may remove any need for stored procedures. If there is a need, then stored procedures may be used by the DAL and such details will be hidden from the user.
6) Stored procedures are fragile.
6.1) I have had stored procedures "just disappear" (that was with SQL Server 6, I doubt the problem still exists, but it makes me nervous).
6.2) Stored procedures are too easy to change in the field. All code changes should be in source control, properly built, and deployed to the field in a controlled manner. SQL in code accomplishes that.
As mentioned, you absolutely must use parameterized statements. I think one reason people insist on stored procedures is because they force the developer to use parameters. But inline SQL can (and should) use parameters and a well-disciplined developer will have no trouble doing so. I have written several families of classes that make data access with parameters a no-brainer. Here[^]'s one.
|
|
|
|
|
Stored procedures can help reduce network traffic, as the EXEC statements are typically shorter than the statements in the SP's. Naturally, this depends on if network traffic is an issue at all (e.g., if the SQL runs on the same machine as the C#, it wouldn't be an issue... it also wouldn't be an issue of the data being transferred dwarfs the SQL code size).
DLL's are just as fragile as stored procedures. At my previous job, we had to work with a system that had hundreds of DLL's and OCX's. The systems constantly got out of sync. SP's have one advantage in this respect... you fix them in one location (the database) and they are fixed everywhere. That's kinda nice (at least for systems where there is a primary database server). The other advantage/disadvantage is that you can see the stored procedure code, while it is difficult to see DLL code (without, say, Reflector). That means that you can easily check if the wrong code is in use, but it also means its more tempting for others to modify it on the spot without bothering with version control.
PIEBALDconsult wrote: I have had stored procedures "just disappear"
SP's should be kept under version control. Sadly, the tools to do this are not excellent. Though, I remember a tool from Redgate under development that is supposed to help with this.
PIEBALDconsult wrote: Stored procedures are too easy to change in the field.
Shhh, don't tell this to Microsoft... they might think making things "too easy" is a bad idea. 
Depending on the scenario, this may actually be a good thing. Rather than trying to deploy the code to each computer that uses it, you can simply update the SP's on the server and you're done. This also brings up security concerns. It can be difficult or impossible to control security if you allow the clients to run arbitrary SQL statements. If you have stored procedures, you can control exactly what executes on the server. This is a very important point, as it may be the single greatest advantage stored procedures have over plain SQL code.
PIEBALDconsult wrote: one reason people insist on stored procedures is because they force the developer to use parameters
string firstName = "'; DROP TABLE Whatever; --";
string cmd = "EXEC SelectData '" + firstName + "'";
Both stored procedures and plain SQL are susceptible to SQL injection.
|
|
|
|
|
aspdotnetdev wrote: Stored procedures can help reduce network traffic
Yes, but mine never go across a network so that argument has no weight for me.
aspdotnetdev wrote: you fix them in one location (the database) and they are fixed everywhere
Not if you have many clients each with his own database. And you should be putting the code in a version control system, that makes at least two places.
aspdotnetdev wrote: It can be difficult or impossible to control security if you allow the clients to run arbitrary SQL statements.
That's what a DAL is for.
aspdotnetdev wrote: If you have stored procedures, you can control exactly what executes on the server.
You can. But do you? It's much easier with compiled code.
aspdotnetdev wrote: Both stored procedures and plain SQL are susceptible to SQL injection.
Huh, OK.
|
|
|
|
|
Always Stored Procedure because
it will provide protection from SQL injection attacks,
it enable conditional and procedural logic,
it provide better management of Compilation and storing or Execution plan
it enable of security model and
stored procedure code is a lot more readable
modified on Wednesday, October 27, 2010 2:35 AM
|
|
|
|
|
|
use store procedures in database because if you have any problem, you only needs change the proc to resolve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
