|
Only when I have finished banging my head on the desk.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Are you at it again, wasn't this stretch day for you?
|
|
|
|
|
I know how to show a UserControl(WPF) by ElementHost in
a form.
like this:
private ElementHost m_elementHost;
private UserControl1 m_uc;
private void button1_Click(object sender, EventArgs e)
{
m_elementHost.Child = m_uc;
}
but I want to do show UserControl1 not use ElementHost, like this:
private void button1_Click(object sender, EventArgs e)
{
UserControl1 uc = new UserControl1();
uc.Show();
}
|
|
|
|
|
If you're asking how to show a WPF UserControl in a Windows Forms app without using ElementHost, you can't. ElementHost is required.
|
|
|
|
|
|
Stick the user control in a WPF Window; then you can "show" it. Hide the window's "chrome" if that's a problem. Same result.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
|
I am running a Windows Service that executes successfully every 10 minutes. It instantiates an in house dll file and calls a method to do some process. This dll file logs everything throughout the process. Now the problem is I have no clue where this log file is anymore!!
Normally when we use this dll file and call its methods, it will create a folder called "Custom" inside the application path with log files.
I do not see any Custom folder anymore even tho my code runs and I see the results.
How do I find where my dll related log files are?
|
|
|
|
|
Hi,
I don't think the DLL file is relevant, services use their own default directory and any DLL they reference would use the same. I guess this[^] will offer more than you are asking for...
|
|
|
|
|
Hi,
Thanks for your reply. The registry key only holds the path for the service executable file. And I already know where my service has been installed. I can also see the dell files in there. But I do not see the custom folder and log files that the dll file is generating. They are not in that path.
|
|
|
|
|
Hi,
to make sure what file operations are executed, use Process Monitor[^] as Dave already suggested.
My best guess is this: as a service, your code is using C:\Windows\system32 as its default directory; and it won't have sufficient privileges to create a folder or file there, so nothing gets created, and the exceptions got caught and swallowed (which is always a bad idea). If correct, I suggest you set another default path before calling your DLL, using a location that is not full of system files.
|
|
|
|
|
You can use ProcMon[^] to watch the file operations of your service.
|
|
|
|
|
It is difficult to say anything without seeing your code. It depends on how your code resolves the path.
Program Files folder is generally not accessible to programs and services, you'd have to write log files to User Profile Directory which is usually C:\Users\<username>\AppData.
Shameel,
http://thedeveloperspace.com
|
|
|
|
|
Search for the file name / mod dates on the drive and / or in program data or user data.
Have a coffee and let it search.
(Check the Windows / custom app "event" logs).
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
Hi Experts
Situation:
As soon I instantiate a class which implements IDisposable as a member in one of my own classes I make my class also IDisposable; this e.g. in case I instanciate AutoResetEvent or any other synchronization stuff.
My colleagues argue I'm too nitpicking.
So my simple question: Am I to nitpicking in this case?
Btw: I break my rule in case I instantiate e.g. Font 
Thank you very much in advance for your comments.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
If your class owns a disposable resource, then it should implement IDisposable. That's not nit-picking; that's just good hygiene.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you very much 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
Sorry to disturb again...
In connection with IDisposable: Should I ever take an attempt to have something like try catch/ finally in protected virtual void Dispose(bool disposing) or is it better to take it as the final destaster if an exception happens in Dispose of "my" owned properties?
My opinion: If something strange happens at this low level I do not need to try (I'm anyway not able to) to solve it.
Thank you very much in advance.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I generally avoid it. The Dispose method isn't supposed to throw manageable exceptions, so if you're just calling Dispose on other managed objects, you shouldn't need to worry about it.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Great again, thank you so much.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I would at least log it, and figure out why.
The implication is, if it was a "file resource", the file was not closed properly, and so forth.
Ignoring "end of job" problems is not a "thoughtful" solution.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
Quote: I would at least log it
Yep, not a bad idea. Nevertheless it is very low level and I think at this level it is ok also to fail without a log.
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
On the other hand, a memory leak can bite you days+ later.
That's the poster child for IDisposable.
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.'
― Confucian Analects
|
|
|
|
|
You are right, I need to change my mind
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
I'm lazy, so... Please, read this very interesting CP article: Implementing IDisposable and the Dispose Pattern Properly
There you'll find final conclusion:
Quote: As you can see, there are a lot of details involved in properly implementing IDisposable and the Dispose Pattern. However, by following the proper template and rules, you can ensure that your disposable objects are handled correctly and behave as first-class citizens in the garbage collection process.
But Eric Lippert in this article: When everything you know is wrong, part one | Fabulous adventures in coding has got another one:
Quote: I’ve written a lot about the perils of C# finalizers / destructors (either name is fine) over the years...
... here are a bunch of things that many people believe about finalizers, all of which are wrong.
...
All of the myths so far imply that if you have code that absolutely, positively must run because it has some important real-world impact then a finalizer is not your best choice. Finalizers are not guaranteed to run.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
