|
Hi ,
At the moment I'm developing an Windows Form application and looking for a logger. I have seen log4c++ and boost.log, but both loggers won't work because some code isn't compatible with /clr code. Does somebody has a logger which is compatible with Windows forms?
|
|
|
|
|
|
Hello All,
I haven't coded a lot in Winforms C#. In any case I need to fetch a temporary stored image image from the local disk and process in a vendors API. Their method requires Bitmap bitmap for the parameters as indicated here(//vendor.Reader.AnalyzeField(Bitmap bitmap)).
// Example 1 - This works when I use hard coded texted.
// Example 2 fails attempting to use with the variable. The error is "Parameter is not valid".
1 - Bitmap btm = new Bitmap "C:\\Images\\2.tif");
// The variable fails here.
2 - Bitmap btm = new Bitmap(_transferFile);
//Perform recognition
result = vendor.Reader.AnalyzeField(btm);
Thanks in advance
modified 11-Jul-13 14:03pm.
|
|
|
|
|
fincity wrote: The error is "Parameter is not valid".
Then you need to use a parameter that is valid, i.e. a Bitmap as specified in the method definition. You have not specified what type _transferFile is, but I assume it is not a Bitmap.
Use the best guess
|
|
|
|
|
You mean something similar to below code?
string fileName = "C:\\Images\\2.tif";
Bitmap btm = new Bitmap(fileName);
result = vendor.Reader.AnalyzeField(btm); Where is the initialization-code of your _transferFile member?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
In Windows form , I'm displaying a Project_Table using tableAdapterManager.
I followed as per http://www.youtube.com/watch?v=3w2JkLcp-UA[^]
Project_Id int Primary Key with Identity specification as identity
Project_Name nvarchar(50)
Project_Type nvarchar(50)
Platform_Type nvarchar(50)
Start_Date date
Customer nvarchar(50)
In the code
private void project_TableBindingNavigatorSaveItem_Click(object sender, EventArgs e)
{
this.Validate();
this.project_TableBindingSource.EndEdit();
this.tableAdapterManager.UpdateAll(this.pLMDataSet);
}
I'm getting error Cannot insert explicit value for identity column in table 'Project_Table' when IDENTITY_INSERT is set to OFF
Even after executing following script I'm getting same error. 
USE [PLM]
GO
SET IDENTITY_INSERT [dbo].[Project_Table] ON
go
Another table Phases_table has dependency on Project_Table through FK constraint. Is the error because of this constraint?
Are there any sample examples on C# with MSSQL database which use multiple windows forms with multiples table linked in an hierarchy?
|
|
|
|
|
Member 8387808 wrote: I'm getting error Cannot insert explicit value for identity column in table 'Project_Table' when IDENTITY_INSERT is set to OFF
Means you're passing in a value for the primary key - but that column is readonly, as the database will generate a value for you.
Member 8387808 wrote: Another table Phases_table has dependency on Project_Table through FK constraint. Is the error because of this constraint?
Can you explain me the difference between a PK and a FK? If not, no problem - we'll start there.
Member 8387808 wrote: Are there any sample examples on C# with MSSQL database which use multiple windows forms with multiples table linked in an hierarchy?
Yes. Now a bit more specific, or I'll have to point to a random db-application.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well, I'm plum out of ideas. I've got a listbox with a List<> for its DataSource. When I init it - before the form is displayed, it works. But not after that. I am modifying the List<> contents and then I run:
public void RefreshLbx()
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}
where _quotes is the List<>
Now here is where it gets weird. I put a button on the form - here's its handler:
private void btnRefresh_Click(object sender, EventArgs e)
{
RefreshLbx();
}
So that when I click on the button then the lbxQuotes listbox is properly updated. But in the modification code - where I call RefreshLbx() directly, nothing happens.
I even tried invoking btnRefresh_Click() in the code, but alas could not find the magic.
Oh one other thought - the modification code is in a timer event handler - could this be a problem of trying to modify a control from a different thread? All I am doing is changing the List<> contents and then reseting the DataSource.
I must be missing something to kick the listbox to redisplay, or something... HELP!
|
|
|
|
|
Wow but this is weird. Okay, I found the solution because I tried the recommendation given below:
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
lbxQuotes.SelectionMode = SelectionMode.None;
lbxQuotes.SelectionMode = SelectionMode.One;
That is, I added the SelectionMode two lines... and this caused (only once) a "from different thread" exception. Weird, I'm NOT running a method - I'm changing data... hmmm... I wonder if the DataSource is instead a Property (which secretly runs a method). D'oh!
Okay, so the solution was to create a delegate in the main form, for the RefreshLbx method, and have the RefreshLbx method recursively call this, as below:
public void RefreshLbx()
{
if (lbxQuotes.InvokeRequired)
{
lbxQuotes.Invoke(_refreshLbx);
}
else
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}
}
with the _refreshLbx delegate defined in the form's class as:
private delegate void RefreshLbxDg8();
private RefreshLbxDg8 _refreshLbx;
Then just init the delegate in the form constructor (after the InitializeComponent() call):
_refreshLbx = RefreshLbx;
Now I am able to update the listbox contents from a timer handler.
|
|
|
|
|
"System.Threading.Timer" is not threadsafe. You didn't use the Timer from the Toolbox, did you?
rbsbscrp wrote: Weird, I'm NOT running a method - I'm changing data... hmmm...
You're changing a property from a different thread than where the control was created.
rbsbscrp wrote: if the DataSource is instead a Property (which secretly runs a method).
Yup, it's a property; meaning it's built from two methods (not threads!)
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
You can NOT so much as touch ANY part of a control from a thread other than the one that created it, the UI (or startup) thread. This is where your entire problem comes from.
You have to Invoke methods on the UI thread that manipulates the control for your calling code.
|
|
|
|
|
My thanks to all who responded.
>>
You can NOT so much as touch ANY part of a control from a thread other than the one that created it, the UI (or startup) thread. This is where your entire problem comes from.
My confusion was mostly that I was not trying to run a Method at all - I was just changing a Property (or what I thought was DATA). Upon more consideration, I realized that a Property is just syntactic sugar over a procedure call, anyway, so the "you can't run code from a different thread" rule applied even changing a Property.
However, I am mystified as to WHY this rule "no touchie from different thread" even exists. Sure, if I'm trying to update a TextBox from other threads then there *could* be confusion and a random mix of characters added from the various threads due to the asynchronous timing of the code in the different threads. Yes, there *could* be... it is *possible* - just like I could really mess up a data structure if I update it from many threads without synchronization.
But that is exactly what multithreaded coding is all about - synchronizing the use of common data structures (at least it is a major issue, if not the biggest issue).
But why would the compiler assume that I am needing multithreading synchronization when updating a Textbox? The truth is, I am doing something at timed intervals - I am using a timer. It just so *happens* that C# chooses internally to implement a timer via a separate new thread. That is not *my* problem. I'm not trying to append text to the textbox from 17 different timers or asynchronous threads. I'm simply trying to update a textbox at constant intervals - in this case the system chooses to do this via ONE (other) thread.
Suddenly now I have to become fully knowledgeable about multithreading and delegates and "invoking", etc. BAH! Unnecessary, unneeded, unwanted complexification.
Aside from all that, I especially did not appreciate that the code simply failed to do anything - I got no compiler warning/error nor any runtime problem. My dialogbox simply didn't update. Then I had the fire up The Google and go searching for why it didn't work. My first real clue was that if I caused the update to happen from the very same function, via a click of a button on the UI, then it worked. Whaaa? My code definitely worked, but only if executed via a pushbutton.
I've coded for years, and I'm teaching myself C# now, and "yeah" this is a noobie kinda problem, but geeeez what an unnecessary timewaster.
Okay, 'nuff whining. Thx to all who replied. I found some code example for doing a "invoke" via a deleagate, etc., etc., and got it working.
|
|
|
|
|
rbsbscrp wrote: It just so *happens* that C# chooses internally to implement a timer via a separate new thread.
The timer from the toolbox doesn't; it's simply a component that raises an event at a specified interval.
rbsbscrp wrote: That is not *my* problem.
True - you're simply using the wrong timer-control. (Yes, there's more than one)
rbsbscrp wrote: I found some code example for doing a "invoke" via a deleagate, etc., etc., and got it working.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Wow! You have such a myopic view of what's going on.
The reason you need Invoke is because controls are NOT thread safe. What you see in the toolbox are .NET wrappers around standard window variants you find in Win32. They are not thread safe because of limitations in the Windows user interface. The golden rule is that any operation on a control is required to be done by the thread that created the window handle. It's possible to wrap all this code in synchronzation code, but that would have been a ton of code and a rather large performance hit.
But, but, but "I'm just changing a property!" Yeah, I know. A property is nothing but a method that gets/sets a value, but that method can also do other things like validation, modifying other values inside the control, updating the controls internal state machine, kicking off events, and whatever else the controls need.
What you're forgetting is that Windows is a shared system. Not only can your code cause code in the contorl to run, but Windows can too, AT ANY TIME. It can send your control a WM_PAINT message to get your control to repaint itself, but, what if you were changing the Text or Forecolor properties, from your thread, at the exact same time the control was getting these values to use in the paint code??
Invoke is there because .NET, like any other application, has to follow the "UI thread rule" like any other application.
A little tidbit: The only methods on controls that ARE thread safe are Invoke, BeginInvoke, EndInvoke and CreateGraphics.
|
|
|
|
|
Wow! You have such a myopic view of what's going on.
I don't think so. Let's revisit this one more time.
So I'm supposed to put all code that modifies a control into wrapper code that calls invoke and this wrapper code ends up being a conditional test to see if invoke is required and then recursively calling the same function thru a special delegate that is created just for that invoke call. I've repeated my example code below:
private delegate void RefreshLbxDg8();
private RefreshLbxDg8 _refreshLbx;
...
_refreshLbx = RefreshLbx;
...
public void RefreshLbx()
{
if (lbxQuotes.InvokeRequired)
{
lbxQuotes.Invoke(_refreshLbx);
}
else
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}
}
All this is required in order that the code gets executed on the GUI thread. Now, I'm simply updating a textbox with a sample (number). Nothing else.
I guess I could have stated my point better: yes, it is an asynchronous system and it is *possible* that a WM_PAINT would get processed while the textbox text is changing. I am aware of this. My complaint was that .NET designers used this sledgehammer solution to prevent any presentation rendering mishap (ie. my number is rendered while it is changing) by constraining all code to execute on the GUI thread. So this means that for every single interaction with any control - and there's a LOT of them, I'm supposed to write wrapper code around everything, and this wrapper code involves defining and creating delegates and rewriting all my code to include a conditional statement which tests for this invokability.
AND YOU'RE FINE WITH THIS.
Me, I think this is a horrible and terribly primitive solution and design. It would be better to leave me with using SendMessage() to inject my action into the GUI's Message-Loop.
And that's not to mention that the compiler gave no warnings, there was no runtime error, the code SILENTLY failed, and I had no idea that the timer implemented its actions with a (hidden) separate thread.
I am LESS than impressed.
|
|
|
|
|
Liek I said, it's a limitation in Windows Win32 since the dark arges, not .NET.
If this bugs the crap out of you, go write code for Linux.
|
|
|
|
|
A SendMessage() call works between threads... at least I thought it did. Thus I thought this was a .NET constraint.
If it's not a .NET new constraint then I just learned something.
Dave Kreskowiak wrote: go write code for Linux.
No! (so there)
|
|
|
|
|
rbsbscrp wrote: No! (so there)
Then quit bitching...
|
|
|
|
|
Dave Kreskowiak wrote: Then quit bitching...
Your discourse is not civil, but constant.
|
|
|
|
|
Let it go. It's like looking at a game who will have the last word on a subject.
FWIW; Linux/Mono would react exactly the same.
|
|
|
|
|
rbsbscrp wrote: Me, I think this is a horrible and terribly primitive solution and design.
Microsoft had the same idea; that's why the threaded version of the timer isn't in the WinForms designer-toolbox. The Timer from the toolbox simply raises events on the GUI-thread. No syncing required.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hmmmmm... I am using a System.Windows.Forms.Timer. Isn't that the one you are referring to that doesn't use a separate thread? Okay, now I'm confused. My code works if i execute it from a button. It works if I invoke it thru a delegate. Other than that nothing happens.
|
|
|
|
|
Let me add to the confusion; there's not two, but three[^] timers available.
So, which timer is it? 
..and there's a picture in that article of a second timer in the toolbox. Nice to see my previous post invalidated that quickly.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Wow, wonderful article.
Again, the timer that I'm using is the System.Windows.Forms.Timer one (I'm cut&pasting this from the <class>.Designer.cs file - and I don't see any other timers)
Thx for the article. I'll look at all this in a bit.
|
|
|
|
|
rbsbscrp wrote: the timer that I'm using is the System.Windows.Forms.Timer one
That one runs on the UI thread, and doesn't need any invocations to update controls created.
using System;
using System.Windows.Forms;
using System.Threading;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Thread.CurrentThread.Name = "UI Thread";
}
private void timer1_Tick(object sender, EventArgs e)
{
Text = String.Format("{0}, {1}", Thread.CurrentThread.Name, Environment.TickCount);
}
}
}The timer is based on the Windows message-pump;
protected override void WndProc(ref Message m)
{
if (m.Msg == 275)
{
if ((int)m.WParam == this._timerID)
{
this._owner.OnTick(EventArgs.Empty);
return;
}
}
else
{
if (m.Msg == 16)
{
this.StopTimer(true, m.HWnd);
return;
}
}
base.WndProc(ref m);
}
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
