 |
 |
Apologies for the shouting but this is important.
When answering a question please:
- Read the question carefully
- Understand that English isn't everyone's first language so be lenient of bad spelling and grammar
- If a question is poorly phrased then either ask for clarification, ignore it, or mark it down. Insults are not welcome
- If the question is inappropriate then click the 'vote to remove message' button
Insults, slap-downs and sarcasm aren't welcome. Let's work to help developers, not make them feel stupid.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
 |
For those new to message boards please try to follow a few simple rules when posting your question.- Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
- Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
- Keep the subject line brief, but descriptive. eg "File Serialization problem"
- Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
- Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
- Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
- If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode "<" (and other HTML) characters when pasting" checkbox before pasting anything inside the PRE block, and make sure "Use HTML in this post" check box is checked.
- Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
- Please do not post links to your question into an unrelated forum such as the lounge. It will be deleted. Likewise, do not post the same question in more than one forum.
- Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
- If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
- No advertising or soliciting.
- We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
 |
I have just spent the last 2 days using language I thought I had forgotten - all in reference to Microsoft's decision to declare all their ControlDesigners as Internal. All I am trying to do is inherit some controls from standard controls, and use a ControlDesigner to make their size fixed in one direction or the other. Most will be fixed height or fixed width panels but there are a couple of other controls I'd like to play with in this way also. Overriding the SetCoreBounds method, and the Width, Height, and Size properties to make them all operationally ok has been simple enough, and I have that all working. I just personally think that if a control has a fixed height or width, then it shouldn't show the corresponding sizing handles.
I have created basic ControlDesigners that do this perfectly, all following the pattern below:
class FixedHeightControlDesigner : ControlDesigner {
FixedHeightControlDesigner() {
AutoResizeHandles = true;
}
public override SelectionRules SelectionRules {
get {
return SelectionRules.LeftSizeable | SelectionRules.RightSizeable | SelectionRules.Moveable;
}
}
}
I have also created designers with this pattern that inherit from ParentControlDesigner and ScrollableControlDesigner for controls that require those sorts of properties.
The problem is, when I apply this designer to an Inherited control, that control's normal designer is replaced. This means that I don't get the nice little dotted lines around a Panel, or the popup property editors on controls like the ListView or TabControl.
Life would be so much simpler if I could inherit directly from classes like the PanelDesigner, ListViewDesigner, or TabControlDesigner directly, and just add my little SelectionRules override to that. But I can't.
At the moment, the only solution I can see is to copy the source for these Designers, rename them, and pop my snippet in there (not the way the concept of code re-use was envisioned, I'm sure). If anyone can think of a better way, I'd be wrapped.
Cheers,
Mick
------------------------------------------------
It doesn't matter how often or hard you fall on your arse, eventually you'll roll over and land on your feet.
|
|
|
|
 |
You're covering a wide spectrum: Windows Forms controls / designers; web controls; obsolete(d) designers...
You should pick one designer to try and "solve"; everybody's attention is too scattered otherwise.
|
|
|
|
 |
I've put this question in the .NET folder since I guess this question is more related to the .NET framework than to C# or C++/CLI.
I'm currently struggling to find a way to load and unload a WPF assembly from an arbitrary path (not a sub directory of the base path) from a C# console application.
I was exploring codeproject for a couple of days (as I have done with some other forums), but I can't actually find a way how to get the console application loading the WPF assembly and instantiating an object from the assembly.
Starting point is the following example as C# console application:
using WPFLibrary;
namespace Caller
{
class Program
{
[STAThread]
static void Main(string[] args)
{
SampleWindow wnd = new SampleWindow();
wnd.ShowDialog();
}
}
}
and the following code as WPF assembly:
namespace WPFLibrary
{
public partial class SampleWindow : Window
{
public SampleWindow()
{
InitializeComponent();
}
}
}
I found various similar questions and suggestions to use:
- Reflection via: Assembly.Load();
- Using Activator.CreateInstance();
- Using a different AppDomain with CreateInstanceAndUnwrap
- Using AssemblyResolve for the AppDomain etc.
- etc
But I could never get my simple example above working if the WPFLibrary is not in a sub directory of the base path of the Caller console application. Since I'm new in this field I may just have missed a simple thing or this scenario may be completely impossible.... Any help would be appreciated.
Background of this question:
In case you are not interested to understand my motivation for this question just skip the remaining of this post. We are developing an c++ dll application for a commercial CAD system. The interface for this system is c/c++ only so there no way to change the complete code to a C# application. This application includes a simple scripting language which also allows to define and execute a graphical user interface. Currently this is encoded in a win32 / MFC way, but since it includes a self build layout manager it is obviously a good idea to think about other alternatives. A perfect match seems to be use use WPF, but that requires to use .NET and to allow XAML definitions a C# library connected by a C++/CLI dll seems to be a good setup.
Some major requirements are:
- The WPF dll must be able to be load from the installation of the application.
- It is required to stop and restart the application (so also the WPF assembly needs to be removed and reloaded).
|
|
|
|
|
 |
Thank you for the answer, however this is one of the things which does not work. Assembly.LoadFrom is retrieving the assembly from the one position while instantiating the SampleWindow trys to retrieve it from the Caller path and therefor fails with an exception.
|
|
|
|
 |
achimschoen wrote: SampleWindow trys to retrieve it
That makes no sense. SampleWindow doesn't do anything according to your code. It does work.
|
|
|
|
 |
Just put my small example to a Visual Studio 2010 compiler and add the follwing code:
static void Main(string[] args)
{
string strPath = @"d:\path";
Assembly.LoadFrom(strPath);
...
Make sure WPFLibrary.dll is not in the base directory but only in d:\path.
|
|
|
|
 |
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[^]
|
|
|
|
|
 |
No idea what that means, but here[^] you can copy/paste and see for yourself
50k exceptions in a second. Your definition of "expensive" may vary from mine, ofc.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
 |
Exception is Expensive I agree.
But tested in console application on i7 processor, and time 500ms?
It seems to me this is some delay.
|
|
|
|
 |
There's also a "timeout" on NetworkStream.
I don't know if it has any relation to the timeout on TcpClient.
|
|
|
|
 |
ReadTimeout NetStream returned GetStream() is same as TCPClient.ReceiveTimeout
|
|
|
|
 |
Did you time the GetStream() separate from the Read()?
|
|
|
|
 |
I tried it's, but time not changed.
|
|
|
|
 |
Well, which took longer? The GetStream() or the Read() ... or you don't understand what I'm talking about.
|
|
|
|
 |
GetStream() 0ms
Read() 530ms
|
|
|
|
 |
Message Removed
modified 9-Sep-16 16:38pm.
|
|
|
|
 |
This is a test of the CP Forum posting system. If this were an actual posting, it would include useful content and might provide some context for a question.
Seriously though, I'm not going to click your link. Please explain what you need assistance with in as much detail as you can provide.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
 |
I want to avoid referencing anything related to VB if at all possible.
Is there a C# equivalent to Microsoft.VisualBasic.FileIO.TextFieldParser floating around anywhere?
EDIT ======================
As a quick fix, I came up with the following. I don't know what all the VB version does, but this code appears to correctly parse quoted strings...
public partial class TextFieldParser
{
public TextFieldParser()
{
}
public string[] ParseFields(string text)
{
string[] parts = text.Split(',');
List<string> newParts = new List<string>();
bool inQuotes = false;
string currentPart = string.Empty;
for (int i = 0; i < parts.Length; i++)
{
string part = parts[i];
inQuotes = (inQuotes || part.StartsWith("\""));
if (inQuotes)
{
currentPart = (string.IsNullOrEmpty(currentPart))? part : string.Format("{0},{1}", currentPart, part);
}
else
{
currentPart = part;
}
inQuotes = (inQuotes && !part.EndsWith("\""));
if (!inQuotes)
{
currentPart = currentPart.Replace("\"", "");
newParts.Add(currentPart);
currentPart = string.Empty;
}
}
return newParts.ToArray();
}
}
".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
modified 9-Sep-16 12:27pm.
|
|
|
|
 |
For CSV / TDF files, I tend to use this library[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
 |
Actually, I'm writing a (evidently much lighter) CSV parser, and was gonna write an article, but now I don't know.
".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
|
|
|
|
|