Click here to Skip to main content
15,393,377 members

Comments by tgrt (Top 27 by date)

tgrt 2-Mar-15 8:12am View
Good deal. I'm glad you got it working.
tgrt 17-Nov-14 23:51pm View
This stinks of an overzealous anti-malware program.
tgrt 3-Mar-14 8:07am View
Glad to hear it!
tgrt 22-Jan-14 16:50pm View
That doesn't necessarily mean there's a problem with your code. The variable nextHtmlNode is setup to be null if the node "//a[@id='pnnext' and @class='pn']" isn't found.
tgrt 21-Jan-14 13:46pm View
What are the effects of it not working specifically? Are you getting the alert saying Record not added? If so, that means your catch block is kicking in. It's not written well. It's catching everything (something you should rarely do) and it's tossing away your exception information.

Change the catch block to accept an exception and then write that out so you can see what's happening. Use ToString so you get all of it including the stack trace.
tgrt 1-Dec-13 23:14pm View
Thank you. I agree the design might be a bit smelly, but then again this was just a manufactured example to illustrate the point. I'll give the OP the benefit of the doubt.
tgrt 28-Nov-13 13:10pm View
Make sure the assembly is in the discovery path first. Next use the assembly binding log viewer (fuslogvw.exe) to determine exactly what is happening.

Here's the help topic that talks about using it:
tgrt 18-Nov-13 10:44am View
Thank you!
tgrt 14-Nov-13 23:04pm View
What is the inner exception?

That error should have an inner exception, and it usually gives you the answer. I'm guessing the problem is that you're asking it to deserialize the root element CRMMessage, but the actual root is the pre.
tgrt 14-Nov-13 8:18am View
I would, but then it would just get downvoted. I think he's saying that the XML will always return one row, but the problem is that he doesn't know how to deserialize the XML.
tgrt 13-Nov-13 15:26pm View
The XML you provided only has one row (id 168209). So always having one row is the correct behavior.
tgrt 3-Nov-13 14:59pm View
You need to catch the unhandled exception that is being reported, so that you can get more information.
tgrt 1-Nov-13 12:45pm View
Thanks Bill.
tgrt 31-Oct-13 15:46pm View
You're welcome.
tgrt 27-Oct-13 20:11pm View
You can name the Execute method anything you want. That is, your command instantiation can be: AddUserCommand = new DelegateCommand(AddUser, CanAddUser);

In that case, you'd have two methods with the same signature as Execute and CanExecute currently have.

The only reason to use a parameter in your scenario is if you want poor maintainability. In other words, there's no good reason to do it that way.

You can also pass in lambdas to the instantiation if you have encapsulated an object that handles this type of stuff. For example:

AddUserCommand = new DelegateCommand(parm => userManager.AddUser(), parm => userManager.CanAddUser);
tgrt 27-Oct-13 20:00pm View
The following site has a good implementation of the DelegateCommand if you're not using Prism.
tgrt 27-Oct-13 19:59pm View
See solution below.
tgrt 27-Oct-13 19:46pm View
Is that all your code? Because, I don't see where your command is being created. You have a property, but you're not setting it. You're binding to that property which is a null reference... So I'm not sure what you're expecting.
tgrt 26-Oct-13 13:40pm View
Tables usually have more than one column. Your query is asking for the column names for a specific table. So the question is, what column do you want?
tgrt 19-Oct-13 11:58am View
I didn't realize you were using the System.Windows.Forms.Timer. It executes on the UI thread. You stated in your original post "...dataTable that's updated from a workerThread", so I surmised that you were doing all of your updates from a worker thread. I would more highly recommend doing something about the inefficient looping through the rows, because of the fact it's running on the UI thread.

I don't know what the overall picture of your solution is, but you could consider the events the DataTable exposes for adding and changing rows.
tgrt 19-Oct-13 11:16am View
The key thing is that the DataTable is not thread-safe for write operations. That means any cross-thread write behavior is undefined. You're not performing any synchronization between your two write operations (one adding and one reading/changing).

Race conditions come up in unexpected ways. The sure bet that it can happen is when you perform operations on different threads that work on the same data.
tgrt 11-Aug-13 8:56am View
I hate to break this to you, but you're never going to be a software engineer. You don't have the boldness to go out and figure things out. All you want is the answer. You also have a bad attitude. No one is going to help you once they figure that out.
tgrt 30-Jul-13 14:17pm View
That article I linked in the solution tells you what you need to do to implement a custom application settings class.
tgrt 28-Jul-13 12:29pm View
I'll try to answer any specific question you might have, but I'm not writing code for you.
tgrt 13-Sep-11 15:48pm View
Much nicer approach to the OP than my solution. :)
tgrt 12-Jul-11 11:46am View
I cannot agree more. Wrap when it makes sense and rethrow with additional state information when it makes sense.
tgrt 6-Jun-11 17:56pm View
Reason for my vote of 3
Bad idea for reasons already mentioned. However, I don't think you deserve a low mark, because its an idea and appears you were open to debate.