I am working in Winform app (ticketing app) where people can create support ticket,close etc.
once you select a particular tree node in left pane (either manually or programatically) it's associated control/view gets displayed in right pane of form.
In few scenarios, even though the particular node is getting selected properly (though code) it's associated control not getting displayed/loaded. To brief,
Under root node, I have a open incident, once I close the incident it disappears from opened section and gets added to history section under treeview.
once click on "create incident" button a new tree node gets created with new ticket number and it's associated control gets displayed on right side of form.
So problem is, if I close a open incident and then click on "create incident"; even though new node getting created and it's associated control getting loaded but the control not getting displayed; instead the closed incident view only shown.
Somehow, the new nodes control getting hidden/jammed inside.
I am new to winform/treeview control.I debugged to see if anything going wrong but couldn't find any; neither Google'ng helped me.
Anyone here have any idea what's going wrong (OR) have you faced the same issue. Please help and let me know how to solve it.
PS: Sorry can't post any code and I know without code it's bit difficult to answer but if you can provide any pointer that would help me too.
When you select a treenode and the associated control is not getting loaded, one of four things is probably happening:
The code to view the control is not executed,
The code to view the control is being executed but does not work properly,
The code to view the control is working properly but it is being executed again or hide the control, or
The code to view the control is working properly but some other code is being executed to hide the control.
Set breakpoints in the code to view the control to see which of these is the problem. Once you have narrowed it down, it should be easier to fix.
Related
I have an application where items can be dragged and dropped between two lists. For this I use react-sortablejs (which uses sortablejs).
When I start my React application normally (in dev mode or deployed standalone) the drag and drop works as desired.
However, as soon as I embed the application in a SharePoint page (using webpart), the drag and drop feature starts to go haywire: the first drop works as desired, but all subsequent drops of the same item result in strange behavior, primarily duplication of the item.
After some debugging, it looks to me like the item remains in the old list and therefore an error occurs when the item is "pushed back" or a duplicate occurs because another item is pushed into the same list.
I therefore don't think that this is a problem of the library itself (also because I haven't found any similar error messages about this), but that it has something to do with SharePoint. I noticed in another context that classic context menus with absolute positioning also cause problems because event.pageX and event.pageY contain different values.
Anyway, at the moment I have no clue to get to the bottom of this problem, so I'm hoping that anyone might have had similar experiences before. Maybe this ticket will help someone else who runs into similar problems in the future.
My problem went away after setting forceFallack to true
At work we are upgrading numerous of our applications to run on .NET Core. We upgraded one of our winforms apps which uses SyncFusion controls and we started seeing a strange behavior.
If you create a TreeView control with the parent item not showing a check box, but have the children show a checkbox. When you click the first child it checks all the children under that parent.
Thinking that we had clearly done something wrong in our code, I downloaded the demo apps from Github. Their CheckboxBinding demo seemed similar (parent items with child items with checkboxes). I updated the code to not show the checkbox on the parent items and ran.
To my surprise, we get the exact same behavior.
Has anyone run into this with SyncFusion TreeView control?
We could observe that you are enabling checkbox for child item and disabled for parent item. But while you checking the first child item, it automatically selects all child . We too checked in your provided example, but we could able to observe that on selecting the item in checkbox , it does select only that particular checkbox item and not all other items. Please find the video for the same from following
Video:
https://www.syncfusion.com/downloads/support/directtrac/general/ze/Checkstate_Treeview-949457604
So kindly check the video and confirm us whether our understanding on the reported behavior is correct. If not, please send us the video that shows the exact issue, it would be helpful for us to proceed on it further. We have ensured it in 17.4.0.55v
Regards,
Vijayalakshmi VR
I have got a list view common control in one window. I have a mechanism that updates the list from within the same window (it works like a charm). However, I got this requirement that I have to update the view from an outside entity, like a dialog or another window altogether. This is where the problem arises.
The list view doesn't get updated when an item is Inserted from outside the window boundary. I have tried doing UpdateWindow() calls in every possible List View NOTIFICATION message there is, but to no avail. I wish someone could help me out on this.
Also, the list view DOES get updated with a new item/row when the whole application window is minimized and drawn back. Weird.
Oh, yeah, thanks to #Remy Lebeau for giving right solution in the comment. This is what he gave
/* window procedure of window where list view exists as a control */
case WM_NOTIFY:
switch(((LPNMHDR) lParam)->code) {
case LVN_INSERTITEM:
ListView_RedrawItems(hMyList, 0, lastIndex);
UpdateWindow(hMyList);
UpdateWindow(hwnd); /* the parent window */
...
Hope this helps someone else looking for a solution.
In UI Automation, when automating the toolstrip items we are facing an issue which is described below
I am adding toolstrip items as follows
this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.toolStripButton1,
this.toolStripButton2,
this.toolStripComboBox1,
this.toolStripButton3});
When running the UI Automation(System.Windows.Automation), UI automation finds the controls till toolStripButton2 (i.e) controls on the left side of toolstripcombobox is getting recognized but on the controls on the right side.(If i make the combobox to go the right most control everything works fine)
Note: In Inspect.exe tool from windows kits, all the controls are shown but when trying to access the last toolStripButton3 returns null.
Here i have attached the simplified code, the buttonCollection is expected to get 3 buttons but it gets only two in my case.
AutomationElement toolstrip = viewTab.FindFirst(TreeScope.Children,
new PropertyCondition(AutomationElement.AutomationIdProperty, "toolStrip1"));
AutomationElementCollection buttonCollection = toolstrip.FindAll(TreeScope.Children,
new PropertyCondition(AutomationElement.LocalizedControlTypeProperty, "button"));
Both ToolStripTextBox and ToolStripComboBox are showing the same behavior.
I would like know what is going wrong my approach.
I've posted one approach which would allow you to access all the buttons, in response to your question at https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/2363de9f-3bf0-48dc-a914-1eef5bcf1482/toolstriptextbox-toolstripcombobox-not-automated?forum=windowsaccessibilityandautomation.
Thanks,
Guy
I have built a class library that acts as a GUI framework that can be inherited by other projects. This application is based on projects Wild and Gemini.
My problem is that upon restoring Avalon Dock's layout using the standard serializer
var layoutSerializer = new XmlLayoutSerializer(manager);
where manager is type DockingManager. The manager restores and empty tab. My guess is that Caliburn Micro cannot find the stored ViewModel (named HomeViewModel). However, I am struggling to confirm this.
I believe my bootstrapper to be correct and that the MEF containers are being setup correctly to allow resolution of external types. I have debugged the project to a point where I think this issue is occurring and in the output window I can see Attach(Home) where the attach is occurring (note, "Home" is the display name of the HomeViewModel). However, I don't know what is wrong with the attach process as this is handled by MEF/Caliburn.
I am really stuck with debugging this an wondered if
Any one could offer any insightful advice as to how to proceed with the debugging process?
Anyone would be willing to take a look at the solution?
I have spent a hell of a lot of time debugging this without any luck and the problem is sufficiently esoteric and illusive as to render most posts here irrelevant to me.
Thanks for your time.
as discussed and after looking on the sample code provided, I understand that the following
HomeViewModel or can say LayoutItemBase is not supposed to be reopened as ShouldReopenOnStartup is set to false
if you close the application while leaving a document open for HomeViewModel it is restored on next start with blank view [Not OK]
Analysis
the SaveState method was correctly honoring ShouldReopenOnStartup value and was not emitting the state for the HomeViewModel but dock manager was still emitting an element for the document.
So upon next restart the LoadState does not find any stored state but a window was created as an element was present in the dock manager's layout state
<LayoutDocument Title="HomePP" IsSelected="True" IsLastFocusedDocument="True" ContentId="d716f824-cfff-4b54-8fd6-2d026a99369a" .../>
you did try to use e.Cancel property of Serialization callback to cancel the event, but seems like it is not supposed to prevent of loading a window but just simply to cancel the event if not needed.
Resolution
So the ideal approach is to close the documents which are not supposed to be restored before saving the layout
here is how I did
ShellViewmodel.cs : Line 279 method SaveState(string)
change the following code
if (!item.ShouldReopenOnStartup)
continue;
to
if (!item.ShouldReopenOnStartup)
{
//this item is not supposed to be restored so close the window before saving layout
IDocument doc = item as IDocument;
if (doc != null)
CloseDocument(doc);
continue;
}