|
It's hard to say. The issue could be inside this external library, or it could be in your code. What I would do is, rather than trying to manage the threading by yourself, make use of the Task Parallel Library (TPL). This is a great way to have your code do threading without burdening you with thread lifetime issues. It's incredibly simple to use.
|
|
|
|
|
I am fairly sure it is inside the external library. It processes the images and create all the threads. I only provide an operator interface and process the results.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
If it's in that library then you have no recourse but to notify the vendor that their library is leaking memory.
|
|
|
|
|
I have gone to the vendor. Since it takes hours and several 100,000 images they cannot reproduce it and cannot deal with it. It is kind of an exponential failure. Once you get one then there is a higher probability of getting the second, etc.
I do not expect a fix at this point but still hope. It is just a very different kind of bug than I have ever seen and in so many different ways. I was kind of hoping that someone else had seen something like this and might have some clues because it would be really nice to fix.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
The only way to fix it is to get the source for the component you're using (yeah, right) and rework the component or scrap the component you're using and use a different library that does the same job, or work up a component from scratch yourself.
|
|
|
|
|
There's no magic bullet to fix threading issues. You can't try and arbitrarily kill threads because you have no idea as to whether or not they are busy. The problem is, doing threading right is hard - very, very hard. I wouldn't accept their answer that they can't reproduce it - if necessary, you could send them a slimmed down version of your code that triggers the leak and let them use that with their debuggers.
|
|
|
|
|
I found the problem. It is a memory leak by design in the TextBox control. There is a feature of this box that allows you to undo a change. By default it is set to infinite. Every time you update the value in the control whether from the keyboard or from the code behind it adds to this buffer. It can be turned off completely by putting a -1 in the number of values to be buffered.
This is well documented in MSDN forums but several years old. Finding the right search key that forces it to go back that far is very difficult.
This is an old tread of mine I just ran across and forgot to update it when I found the answer. I hope this will help others when they do a search.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
I have an usercontrol that contains a toolstrip. The toolstrip is exposed through the usercontrol by a readonly property 'HostStrip' with DesignerSerializationVisibility.Content attribute. In this way we can handle the toolstrip and its contents from the usercontrol.
While using the usercontrol in an application, after adding the elements of the toolstrip, if I copy the whole usercontrol and paste it somewhere else, the elements of the toolstrip get deleted. I need to add them all over again. Why is this happening and can it be solved?
Regards!
|
|
|
|
|
If implementing INotifyPropertyChanged allows you to tell BindingSource when an object's properties have changed (and therefore the form needs to be updated) - how would you inform the BindingSource that a particular record/object is currently read-only (or not)?
I was hoping for another interface to implement, but at this point I'm open to any ideas.
The read-only state comes from another user write-locking the record.
|
|
|
|
|
The framework isn't expecting properties to change from "readonly" to something different. It's either compiled with only a getter, or it's writeable.
You could throw a NotSupportedException prior to setting the value if it's readonly at the moment (and thus cancel setting it at all), but it would not be an ideal solution.
Perhaps a better idea would be to split them, into say, a readonly CurrentFooBarState and a writeonly FooBarSetter.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
It seems to be a big gap in the visual studio data-binding extensions - there is no support for read only entities or even read only properties.
Properties that are compiled as read-only do not get treated any differently.
I even implemented the ICustomTypeDescriptor interface, but the binding source, while it reads off a set of properties for each object, it only checks the "IsReadOnly" property from the first record, and it doesn't even appear to affect how it binds the data source to the controls.
I am coping with the issue by:
1) each entity implements IEditableObject.
2) in the IEditableObject.BeginEdit() method, the entity attempts to acquire a lock. If it cannot acquire the lock, the entity is ReadOnly. I removed any exceptions thrown at this point: the lock fails silently.
3) I have handled the CurrentItemChanged event from the BindingSource. In this handler, I check if the entity is read-only, and update the enabled state of the associated controls.
This seems to be working for now, but I am faced with another issue:
the BindingSource component, doesn't always call IEditableObject.EndEdit() or IEditableObject.CancelEdit() for every item it has called IEditableObject.BeginEdit() on.... this seems like a fairly dramatic design flaw in this component.
Am I not disposing of it correctly?
|
|
|
|
|
Simon Bridge wrote: Am I not disposing of it correctly?
Let's find out; does the thing implement IDisposable? Add it if not, override if it does, and use the method to write a message to the VS-output.
Simon Bridge wrote: the BindingSource component, doesn't always call IEditableObject.EndEdit() or IEditableObject.CancelEdit() for every item it has called IEditableObject.BeginEdit() on.... this seems like a fairly dramatic design flaw in this component.
Soo, it still had focus when being removed from the form? The user didn't cancel his edit-mode, move focus to end editing? What happens if you manually focus something else, like a dead button, before removing it from the form?
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
BindingSource is an IComponent, the main definition of a component being that it implements IDisposable, - so yes it does have a Dispose method, and this is being correctly invoked by the 'Container' on the form when it gets disposed.
However, I think I have discovered the problem. The issue is the record that is currently on-screen (so it's a data-input form with text-boxes, combo's etc. - not a data-grid)
When you close the form, the record currently on screen, (which was put into edit mode as soon as the record became current) is not removed from edit-mode.
Turns out, there are CancelEdit() and EndEdit() methods on the BindingSource object itself. I trapped the Form.Closing event, and invoked CancelEdit() on the primary binding source for the form, and it now releases all the locks.
I put in some logic to determine if the current record has pending changes, and call EndEdit() instead to keep the changes.
This even works when the binding source has other data sources hanging off it (i.e. when a property of the current object/record is itself a data-source ('cos its a list), - on some forms in my system this can cause upward of 50 records being locked at one time, which was causing lots of headaches when they weren't unlocking)
I am still a little unsure why you have to explicitly call either EndEdit() or CancelEdit() from the binding source - I would have put clean-up code in the Dispose method if I were writing the class. My best guess is that the Begin-End/Cancel edit semantics are more closely coupled with the DataRow and DataGridView components.
|
|
|
|
|
Simon Bridge wrote: Turns out, there are CancelEdit() and EndEdit() methods on the BindingSource object itself.
Not exactly where one would expect them, but such things happen..
Simon Bridge wrote: this can cause upward of 50 records being locked at one time
..with bigger implications than expected.
Simon Bridge wrote: My best guess is that the Begin-End/Cancel edit semantics are more closely coupled with the DataRow and DataGridView components.
Every "Forms"-controls is in edit-mode as long as it has the input-focus. It would sound more logical that "editing" would end as soon as the control is disposed of.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I would like to implement a functionality similar to jQuery TagIt into C# windows forms. Here is the link for jQuery - http://aehlke.github.com/tag-it/
I am thinking of creating a user control for this functionality.
Any help on how to go about this?
|
|
|
|
|
Hi
I have a MS Access 2003 application with a MSSQL 2008R2 database and need to re-write it. It is used at HQ and 4 remote branches.
What will be the best tool to use?
ASP.NET webforms
ASP.NET MVC
WPF and WCF
Silverlight
Windows Forms
Where do I start
Thanks
Japie
|
|
|
|
|
Jaap Britz wrote: ASP.NET webforms
ASP.NET MVC
WPF and WCF
Silverlight
Windows Forms
First ask yourself whether it "should" be a Web-application or a Desktop-application. Then consider the GUI that you have most experience with.
Jaap Britz wrote: Where do I start
On MSDN[^] 
|
|
|
|
|
Good point 
|
|
|
|
|
First of all, don't do this!
Second, much easier and better is to write your application from begining to the end. Use SQL Server instead of MS Access database.
You'll find many examples on CP knowledge base (Articles).
|
|
|
|
|
How to deploy a windows application along with mdf file. Here when i install application in client pc. It should maintain database without sql server. I have mdf file of my database. How can i deploy it. I want to deploy as standalone application. Please some one help me to deploy. Step by Step.
|
|
|
|
|
If you want to deploy a standalone application and database also it would be better to use an embedded database. For example: SQLite or SQL Server Compact Edition. In this case database engine is represented by set of assemblies. So you can easy deploy them and database file with your app.
|
|
|
|
|
I've recently brought an old PPC (PocketPC) 2003 project developed in VS 2003 into VS 2008. This converted project has some issues with it so as an alternative to conversion I created a new project a brought the code and forms from the old project, otherwise identical to the original.
One problem is that I'm running into with both the old original and new projects is that if I change a form in any way and then save a new error is flagged by VS: "Constant cannot be the target of an assignment." The error is the same in every form: code generated by the Windows Form Designer, the line that sets name of the form.
Me.Name = "[formname]"
([formname] depends on the form, is something like frmAvailableMaterial, etc). If I delete this line of code the error disappears but the next the time I change the same form, Windows Form Designer again adds the line Me.Name = "[formname]" and is flagged as an error. So the problem keeps reappearing on forms that I have already "fixed". VS 2008 keeps putting back a line that it flags as an error.
For comparison, I looked at a "clean" VS 2008 project that had no forms imported from a VS 2003 project, only forms created within VS 2008. The VS 2008 forms do not show any code generated by Windows Form Designer within the IDE. This form code isn't directly visible to the developer, only indirectly via the form editor. The VS 2003 forms still have this Windows Form Designer code even when brought into VS 2008. Since VS 2008 is having an issue with this form code, it would be ideal if VS 2008 could convert the VS 2003 form to where it would be fully compatible with VS 2008, to where there would be no real functional difference between an imported VS 2003 form and a form created in VS 2008.
Currently, the only work-around that I can think of would be to create new forms within VS 2008 and copy/paste controls and code and manually rewrite events. I'm certain that this would work with the downside being that this would also be a big investment of time and labor. I would like to see if there is an alternative way that permanently fixes this problem but doesn't require a complete reworking of the project. Does anyone know of a way to accomplish this?
You can probably duplicate this error yourself by importing a PPC VS 2003 project into VS 2008 (perhaps it doesn't even need to be PPC).
|
|
|
|
|
The article at this link will help you move the Windows Form Designer generated code to a separate .Designer.vb file for each form in your project.
I don't think, however, that will solve your problem with initializing me.name. My programs all have code to initialize me.name without an error.
I experimented and found that if my code contained a CONST declaration similar to the following declaration, I get the same error as you do.
CONST name as string="Cause an error"
Because of this, I think you have a variable, Sub or Function (maybe a CONST) in your code that is called "name". If so, change it to something else like "thename" and see what happens.
|
|
|
|
|
Parent = context.table
child = From t in parent where ...
In properties, the datasource is set to parent as well.
The bindingnavigators.bindingsource are set to child, all controls and datagrids are bound to the child bindingsoure.
Add new will instaniate a new row. It displays in the datagrids; however, it will not save. The primary key field maintains 0. As soon as I sort or call a new query the row is gone. On reload the row is gone.
Is there a problem with a child binding source?
me.validate()
me.parentsource.endedit()
me.child.endedit()
parent.resetcurrentitem()
me.context.submitchanges()
I have tried ending edit in reverse order and not reseting the current item (needed to update the changes, which works correctly for some strange crazy reason). The problem exists solely with saving a new row.
Does it make a difference that there are two binding navigators? Due to space and design, I opted for 2, but I have tried the addnew on the second.
Hmmm ... Ideas?  (Asked in VB too. Saw the forms forum after.)
|
|
|
|
|
Actually, I solved this in quite an odd manner. I added a textbox for the primary key that was linked (bound) to the parent datasource. This solved the add new.
Why the child could not aquire a key value is beyond me. I simply hid the textbox by placing it behind another control. Oh, that reminds me. You cannot set the visibility to false and the key still add. Again, another thing that eludes me entirely. What does visibility have to do with it? I could not find any documentation that linked the visible status to the enabled status, but ah well. Problem was solved.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
