|
i,m using c#2005 and sqlexpress.
in my projects i use separate class for db connection and call that on project.
there i use connection string as
ConnectionString = "Data Source=.\\SQLEXPRESS;AttachDbFilename=|DataDirectory|\\Database\\stock.mdf;Integrated Security=True;User Instance=True";
as i understand this db created on project location and it attached to sql server when project(or build exe) running. after successfully build project i could see db had attached to server as "D:\Equipmanager\Equipmanager\bin\Debug\Database\stock.mdf"
everything ok.db connection works fine.
but problem comes when i start reports.
there i tried on ADO.net and OLE DB.but wizard shows only default dbs.master etc....(actually my project db attached to server when running.show how it show there?)
here's my problem...
1. can i use this connection string...is there any problem...
2. how to use project db for reporting(use crystal report)..?should i attached db manually and do report?
if i use sql 2000 this problem ok.because there every db is attached and not separate file.
currently i get db details by code and pass those to report(actually this connection string fine.because when deploying db is automatically attached.no need to do it manually)
but passing parameter is not good when long report.that's why i want to find way connect db to report?
|
|
|
|
|
did you try copy your mdf file to near of other standard mdf file, maybe it can checks constant path
|
|
|
|
|
sorry
i can't get what you'r saying.could you please explain
|
|
|
|
|
Sorry for late reply,
you have said that your mdf file is on
D:\Equipmanager\Equipmanager\bin\Debug\Database\stock.mdf, right.
but if you use wizard you said that you can see default database(like master), and i suggest you copy stock.mdf to master.mdf's folder
I wish to it is ok for you
|
|
|
|
|
thx.
but that's not working..
now i use this way
create dataset and populate it using database table and write xmlschema from dataset
then use xml file as database file of report.it works fine
|
|
|
|
|
I have a bug in .NET which I'm trying to repro for Microsoft. To repro this bug, my app needs to respond to events raised by a COM object.
In my app, this object is iTunes. However, for my repro, I want to use a COM object already installed on a common XP setup.
So - are you aware of a COM object I can create in my app, which raises events for which I can create a handler?
Preferably, this COM object has a UI, so I can control when the events are fired. For instance, with iTunes I create an instance of iTunes, then create a handler for the VolumeChanged event, then I click on iTunes and move the volume slider. Each change sends an event to my app.
Anything like this laying around in windows?
Thanks!
|
|
|
|
|
You could write a quick little .NET wrapper around the IE WebBrowser ActiveX control. It implements a number of events, such as when a document has completed loading. You could then control the firing of the event by navigating to a new page.
I'm curious, what is the bug you're seeing?
-Phil
|
|
|
|
|
Apparently I didn't make it clear enough that I didn't want to put that much work into this. 
I'm really looking for a ham sandwich here - a pre-made ham sandwich: an object which launches an application with a UI, that will send me messages. I really don't want to write any more code than I currently am:
itunes = new iTunesLib.iTunesApp();<br />
itunes.OnSoundVolumeChangedEvent += new _IiTunesEvents_OnSoundVolumeChangedEventEventHandler(itunes_OnSoundVolumeChangedEvent);<br />
So, if it's not about that easy, or you don't have the 4-5 lines of coded already written, I'm just too damn lazy to go beyond that.
The bug:
In the app, when I get the message I add it's text to a table, which is bound to a DataGridView. If my app is in the foreground, everything is hunky dory - the event hits, the DataGridViewadds a row, the event text is displayed.
When my app is not foreground (ie, the app raising the events is foreground), two bugs occur:
1. when my app is hosted by VS, no RowsAdded event fires for the DataGridView, and it is not redrawn. So, it looks like nothing appears. Calling dgv.Refresh() will cause the new rows to be shown, yet RowsAdded was never fired, ever.
2. in RELEASE (not hosted by VS), it's worse. Although each row shows up after the event, as soon as there are enough rows for the vertical scrollbar to try to appear, the app "hangs". The cursor is busy, the UI is unresponsive. Clicking the close box on the title bar causes windows to report the app as not responding. Interestingly enough, though, there's no CPU being eaten - no looping.
I've written a really simple sample app to demo this, but it requires itunes. I'd prefer to use a COM object installed on any given XP machine.
|
|
|
|
|
And to follow up - I verified this does not happen when you simply have a timer add rows while the app is not foreground. It's specific to handing events which come from the "outside" of the app.
|
|
|
|
|
When you add text to the table in response to the external application's event being fired, do you do so from the UI thread (say, via Invoke()) or directly within the event handler?
-Phil
|
|
|
|
|
I wrote a simple little iTunes listener that shows similar odd behavior. It's just a WinForm application that has a text box that is updated with the new volume as it is changed within iTunes.
public partial class Form1 : Form<br />
{<br />
private iTunesLib.iTunesApp app;<br />
<br />
public Form1()<br />
{<br />
InitializeComponent();<br />
<br />
app = new iTunesLib.iTunesApp();<br />
<br />
app.OnSoundVolumeChangedEvent += new iTunesLib._IiTunesEvents_OnSoundVolumeChangedEventEventHandler(app_OnSoundVolumeChangedEvent);<br />
}<br />
<br />
void app_OnSoundVolumeChangedEvent(int newVolume)<br />
{<br />
<br />
textBox1.Text = String.Format("{0}: {1}\r\n{2}", DateTime.Now, newVolume, textBox1.Text);<br />
}<br />
}
When the application is run and the volume is changed in iTunes, the textbox won't show the updates (or will, but not dependably). If you comment the "doesn't work" code and uncomment the "works" code, all the updates are displayed. What the example demonstrates is the need to make all updates to the UI on the UI thread, else the behavior of the UI can be undefined. This includes, as far as I know anyway, updates to data bound to UI elements (because those updates indirectly trigger updates to the UI).
(I apologize if this is all old-hat to you already.)
-Phil
|
|
|
|
|
I make my changes directly in the event handler. Well, at least, in methods called by the event handler, but all of those are form methods.
What you are describing seems backwards to me, although I have to admit my understanding of Invoke is very weak. However, it seems to me that the event handler thread IS the form thread - that is, I am using the UI thread to update the UI thread.
Also, note that my updates always show up in RELEASE (as opposed to in VSHOST). However, there's the hanging problem when the DGV gets the scrollbar. Also, note that no problem exists at all in RELEASE, as long as my app is the foreground app...
So, these things may all be related, but the causality is not clear to me.
|
|
|
|
|
The event handler may or may not be executed on the UI thread; it depends on the implementation of the COM object firing the event. (There are some other factors that come into play, too, but they just confuse the issue even more so I won't go into them.) I find that it is best to simply assume that events fired by third party COM objects will *not* occur on the UI thread and code accordingly. It's actually very easy to do. Every UI control (e.g. the Form class) has an InvokeRequired property. You can get the value at any time and it will tell you whether or not you need to use Invoke() in order to update the UI.
While I can't speak for the entire iTunes API, I was able to verify that at least the volume changed event is fired from a non-UI thread. I suspect that the same holds true for the rest of its events. Therefore, you should be using Invoke() at some point within your event handler before updating the UI.
-Phil
|
|
|
|
|
I am going to take your advice, and do this. If I stick the Invoke check right in the handler itself, that should cover any subsequent chains of methods called?
Also - can you explain what you are doing in the Invoke method here? I want to make sure I know what is going on. It looks like you are passing a new instance of the handler?
And finally, do you think the odd behavior in RELEASE is caused by this? And why, under VSHOST, am I not seeing Exceptions thrown (you know, this control was accessed by a thread that didn't create it, that sort of thing)?
Thanks for the help, this has been educational.
|
|
|
|
|
You were right, this fixes every one of the problems I mentioned. You are my personal hero, until my next question.
I still don't understand why "wrong thread" exceptions weren't thrown.
|
|
|
|
|
I was just finishing up an explanation of the Invoke() method and its use when my laptop decided to stage a temporary strike. 
When you call Invoke(), you generally pass two things. The first is the method that should be invoked on the UI thread. It's often convenient to simply pass the method currently executing since the method we want executed on the UI thread will usually have the same signature anyway. The InvokeRequired check prevents an infinite recursion. The second argument passed is a collection of arguments to pass to the method to be executed on the UI thread. If we're "recursively" calling the same method, we just pass an object array with the arguments that the method was given in the first place. (If the list of arguments passed to Invoke() don't match the signature of the method passed to Invoke(), an exception will be thrown.)
The Invoke() method will then place a special message into the application's message queue and wait for it to be picked up and processed by the application's message pump operating on the UI thread. The message contains the method to be called and the arguments to pass to the method. The UI thread will eventually get to and process the message. As the message is processed, the UI thread will execute the specified method and pass it the specified arguments. When the method exits, the UI thread moves on to the next message in the queue and the original caller of Invoke() is notified and allowed to continue.
Finally, a lot of the confusion surrounding the use of Invoke() is exactly what you're seeing. Sometimes (often times) everything works just fine even though the UI is being updated from all manner and number of worker threads. Then you find the right scenario and everything just *stops* for no apparent reason. (I had written one application that ran for days on end when left minimized but would immediately lock up when the first event arrived while the user was actually looking at the form.) I've noticed that Visual Studio 2005 has an improved debugger that will actually (in certain situations and when configured to do so) throw exceptions in this situation so that the problem is more apparent to the developer.
-Phil
|
|
|
|
|
Thanks again. I figured out the delegation eventually, and I did find link to Control.Invoke at
ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.en/cpref17/html/P_System_Windows_Forms_Control_InvokeRequired.htm
It's the InvokeRequired page. That's the only one you can get to from the Index!
Too bad this thread is buried under my "find me a COM object" heading. It's very instructional, I hope others can find it.
Makes me wonder if I shouldn't just wrap every method in an InvokeRequired check.
In fact, it's interesting that InvokeRequired is always there, and it makes me wonder why .NET doesn't simply do the right thing if it knows delegation is required. I have seen the "wrong thread" exception thrown occasionally, in much more subtle circumstances, I'm surprised it's not being thrown here.
Thanks again for the edumacation.
|
|
|
|
|
My guess would be that there is a slight performance penalty with using InvokeRequired. While it may be meaningless for the relatively few event handlers that end-users will call it from, to use it within every .NET library method and property that might ever be called by a user would probably have a more measurable, cumulative impact on performance. Making its use explicit allows the developer to make the appropriate call between safety and performance.
-Phil
|
|
|
|
|
One last question. The only API I'm using with multiple passed objects is this:
void itunes_OnDatabaseChangedEvent(object deletedObjectIDs, object changedObjectIDs)
How do I write the Invoke statement for this? If I pass both objects to new object[], then to access them from the Invoked iteration will require different code than the non invoked iteration.
Do I need to write an overloaded itunes_OnDatabaseChangedEvent() ?
|
|
|
|
|
You would do something like this:
<br />
void itunes_OnDatabaseChangedEvent(object deletedObjectIDs, object changedObjectIDs)<br />
{<br />
if (InvokeRequired)<br />
{<br />
Invoke(new _OnDatabaseChangedEventHandler(itunes_OnDatabaseChangedEvent), new object[] { deletedObjectIDs, changedObjectIDs });<br />
}<br />
else<br />
{<br />
}<br />
}<br />
You create an object array with the arguments in the same order in which the method to be executed on the UI thread expects them. The Invoke() method takes care of pulling the array apart and passing them to the method. (The method called never sees the array; it's just a generic way to pass the arguments to Invoke().)
-Phil
|
|
|
|
|
I figured that out right after I clicked Post...  It occurred to me that Invoke would be smart enough to call the delegate with the correct number of arguments.
You should write an article on handling COM events and the Invoke method. You have explained it well.
|
|
|
|
|
Hi,
you discovered Controls are not thread-safe, and can be only handled coreectly by the
UI thread. Using InvokeRequired and Invoke supports this, but needs the programmer's action.
Having it done automatically could result in terrible performance:
the method you Invoke ends up in a queue, waiting for the UI thread to
become ready to handle it.
So it is the designer/programmer's responsibility to decide which piece of code should
execute on which thread. Imagine a method with a for-loop that updates some Control
(say all items in a ListBox). Rather than having the control do its own Invoke,
a proper design would have the etnire method run on the UI thread, involving only
one Invoke.
This is a design issue. Something similar is true about locking in a multi-threaded
environment (independent of COntrols); locks must be there by design, and
not be inserted automatically.
Luc Pattyn
|
|
|
|
|
No, this hat is the newest, in fact. Can you explain what is happening in the Invoke statement?
Weird, MSDN says this about the Invoke method:
This method is for access to managed classes from unmanaged code, and should not be called from managed code. For more information about IDispatch::Invoke, see the MSDN Library.
Aren't we calling it from managed code?
|
|
|
|
|
My fault, MSDN was describing "_AppDomain.Invoke". Note that MSDN doesn't have a description of Control.Invoke.
And people wonder why newbies like me pound on things.
|
|
|
|
|
Is it possible write a virus program in c#, if it is, can any one give me an example
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
