|
HI,
I Have Created a Desktop Winforms Application On The Basis of Wix.com Means a user can create Html templates in the Application and then Publish Them.now when a user Clicks on the Menu On Right side( Which Contains Menu For Adding Buttons and Other General Controls),The Control is Drawn on The Webbrowser control ( Setting its Editmode true).
But Whenever we add a Control is Alighned to left By Default and There is No Mean To Reorder them .
Can we implement a Functionality Which Lets Users Place Controls on Document where ever they want instead of Having Each control Autoalighned to Left.
Thanx
Tarjeet
Tarjeet
|
|
|
|
|
First, get your finger off the Shift key. You're not using correctly and it makes your post a little difficult to read.
Second, what controls are you talking about?? HTML controls?? Like INPUT tags? If so, you've got a lot to learn about writing HTML and why everything is "left aligned" by default.
|
|
|
|
|
ok but can i break this behaviour of html ??
|
|
|
|
|
You have two choices if you want to continue to use HTML.
1) Use the nightmare that is CSS positioning.
2) Rewrite the HTML spec yourself and write a parsing and rendering engine to use your new spec.
Other than that, we have no idea what you're using HTML for and what your app does, so it's pretty much impossible to suggest any other methods.
|
|
|
|
|
I am finding a new kind of memory link. Maybe not new but new to me. I have an application that generates 50 to 70 threads. I am using a vision library by a third part which generates many of them. My program is a C#/WPF. I think the library was done in C++.
I capture and analyze an image every 60 msec. After 3 to 4 hours I see the thread count for the application rise. This is well over 100,000 images. Every image creates a few threads and then closes them when finished. This spreads the load out over several core. I am watching it in Resource Monitor. Of course as thread count raises so does memory.
Has anyone seen a similar leak?
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
Do not know for sure. But you could try to call Garbage Collection manually after processing an image. Use GC.WaitForPendingFinalizers() and GC.Collect(). Maybe that helps.
|
|
|
|
|
Even if the system is not used for 5 minutes the extra threads still persists. That should be plenty of time for automatic garbage collection to get rid of old threads.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
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 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
