|
Never any need for that Bill - you are Forgiven[^] of course.
(And I love Sharon's voice)
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!
|
|
|
|
|
lovely voice, reminds me a little of Sarah Brightman. thanks, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Please stop singing immediately. this is supposed to be a serious forum.
|
|
|
|
|
Okay, got it ... I'm switching to screaming 
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
That would be fine in Q&A 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
