|
This might help:
COM Callable Wrapper[^]
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
As you can see in the remark section of this command this is only working for sub paths, but not for arbitrary ones.
|
|
|
|
|
If it's simply a matter of "calling WPF in any folder from a console app", then this works:
AppDomain domain = AppDomain.CreateDomain( "newDomain" );
domain.ExecuteAssembly( @"C:\etc\foo.exe" );
Yeah, I know, it's an "exe"; but I don't see where you "need" to instantiate a window only.
In any event, you can communicate across domains.
|
|
|
|
|
I am not sure if the discussion meets the pivotal point of your approach: I think the most problematic part is showing a WPF window from a console application (or later an MFC application). I haven't yet had to do something like that, so I cannot provide details on how to accomplish that.
|
|
|
|
|
The problem you have here is that you aren't actually calling any of the WPF build up behaviour that you would normally see from App.xaml. There's a lot of infrastructure inside WPF that just doesn't exist in the Console world (for instance, how would you expect the Console app to load application resources in a ResourceDictionary), so attempting to instantiate your application like this just isn't going to work. What you would probably have to do is run up the application with an invisible main window, and then call methods inside that instance to fire up the relevant windows that you need.
This space for rent
|
|
|
|
|
The same example I have posted in my initial post does work. It just retrieves the WPF assembly from the same location as the caller application.
|
|
|
|
|
If you have it loading from your local folder, that suggests that the issue that you are facing is because the application cannot find the dependencies it needs. Remember that, just because you have put the DLLs in the remote folder, that doesn't necessarily mean you are using that folder for your references. Whichever technique you pick to load the remote file will have to take into account that its dependencies are going to be remote as well. This isn't specific to just WPF, this applies to pretty much any assembly you load from a remote folder. You will find this[^] is a useful read. Oh, and if you want to load it and unload it, you're going to have to use an AppDomain to loda the assembly into.
This space for rent
|
|
|
|
|
For TCPClient set property ReceiveTimeout in 1 ms.
But time from try read stream to catch IOException is about 500ms.
Why is this? What way can decrise this time?
static void Main(string[] args)
{
byte[] b = new byte[1];
TcpClient tc = new TcpClient("127.0.0.1", 5000);
tc.ReceiveTimeout = 1;
int tick = Environment.TickCount;
try
{
tc.GetStream().Read(b, 0, 1);
}
catch (System.IO.IOException)
{
Console.WriteLine("IOException");
Console.WriteLine("Tick time {0}", Environment.TickCount - tick);
}
Console.ReadLine();
}
Output:
IOException
Tick time 530
modified 16-Sep-16 5:38am.
|
|
|
|
|
|
When there is no data for read, after ReadTimeOut time generated IOException.
But time before catch exception more whan time ReadTimeOut about 500ms.
|
|
|
|
|
|
You should use Stopwatch.StartNew() and then the Elapsed.TotalMilliseconds property for measuring the time. Using the common system clock may lead to wrong values.
|
|
|
|
|
Add use StopWatch, result not change,
|
|
|
|
|
The answer is in the documentation.
try
{
tc.GetStream().Read(b, 0, 1);
}
Look up TcpClient on MSDN. GetStream method does not throw any IOException, so must be the read-method. And yes, MSDN states[^] that an IOException is thrown when:
"The underlying Socket is closed."
Suggestion: open the socket. That might also give a timeout, but a connection-timeout. You should also test for all the exceptions mentioned in the documentation that I pointed to, as it may throw more than IOExceptions if implemented correctly.
Also, ticks aren't updated every ms, so that makes it useless for timing thight code 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
Congrats on repeating.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The process of "handling an exception" is "expensive" (compute-wise).
It involves "unwinding the stack", etc. ... all of which incurs "overhead" that one normally does not encounter if one simply ignored the exception (somehow).
Your objective should be to eliminate or reduce the number of exceptions instead of worrying about the "duration" of an exception.
(Maybe perform I/O on another thread if the "real" issue is UI performance).
|
|
|
|
|
Gerry Schmitz wrote: The process of "handling an exception" is "expensive" (compute-wise).
No, it is not.
Give it a try in a console-app without the debugger attached.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Ok, yours are cheap; the ones I encounter (in my non-console apps), tend to be expensive.
My bad for generalizing.
|
|
|
|
|
Unless a debugger is attached, throwing an exception is not an "expensive" instruction.
Gerry Schmitz wrote: in my non-console apps
Use the exact same infrastructure, and the same applies.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
In my world (kiosks), anything approaching 100ms is "expensive".
|
|
|
|
|
Expensive compared to which other technique?
Checking if your primary key-field is in the database before doing the insert? Checking if you still have all write permission before doing an update?
--edit
If handling one took 100ms, you'd only be able to throw and handle 10. You can throw (and handle) some thousand exceptions in a second.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
modified 18-Sep-16 8:03am.
|
|
|
|
|
"Expensive" in terms of response time for the user.
(Felt it necessary to add some "data base" nonsense?)
A "thousand exceptions per second" and no impact?
That one is easy to prove.
Just try a couple of combinations of .Parse (with / without exception handling; with and without a valid string). No debugger.
Must be an "anomaly"; Or doesn't that fit your "pattern"?
|
|
|
|
|
Gerry Schmitz wrote: "Expensive" in terms of response time for the user.
Expensive is in terms of CPU cost.
Gerry Schmitz wrote: (Felt it necessary to add some "data base" nonsense?)
No, just pointing out that catching the exception is usually less expensive than doing a check. Same pattern applies to files, connections etc
Gerry Schmitz wrote: Just try a couple of combinations of .Parse (with / without exception handling; with and without a valid string). No debugger.
Yes, parsing is expensive. Throwing exceptions is not.
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
