VB6 app works fine on Windows 8 with one exception:
Display form with treeview. Displays correctly.
Click button which displays another form used for entry.
When the new form is dismissed (and a new node added to the treeview) all nodes' pictures and are invisible. The +/- signs display, but not the pictures and captions.
If the form is closed and then re-opened, all nodes are properly displayed until another form is opened.
The two forms involved are both MDI child forms.
Thanks.
I just ran into this problem on a client machine. Unfortunately I didn't have the luxury of rebuilding using VB6 (mscomctl.ocx) controls, which according to the previous comment should work.
However it turns out that if you disable the "Touchscreen keyboard and handwriting panel" service in Windows 8 the comctl32.ocx TreeView control will work properly.
IIRC from prior experience, while the treeview in COMCTL32 (from VB5) has this issue, updating the program to use the VB6-era MSCOMCTL32 treeview should fix it. I don't think we ever found any other fix for the root problem, assuming you can't disable the touch services.
I believe the two treeviews are very similar and this upgrade shouldn't be difficult.
I don't recall if any other common controls had the same issue.
Related
I have an app built in VB in Visual Studio 2012 that works absolutely fine on my windows 10 desktop, but as soon as i use it on my windows 10 tablet i see a couple of issues :
1) any forms that were intended to be smaller than full screen are shown fullscreen anyway (almost as if you're not allowed any windows less than full screen) i can live with that if need be, but surely theres a way around it?
2) - the most important one - for some strange reason, i start my app, and when i click on a button let's say it opens form 6. once i finish what i'm doing the code closes the form 6, but the previous form is now hidden and all you see is the desktop. ie it's still running, it just lost its focus and must be selected again. I understand i could set the focus to the underlying form before closing form 6, but here's the problem : it can be one of several different forms calling form 6..... so how do i make the app stay aware of what form called form6 so that when done i can return focus there?
this doesnt seem to be a problem on the desktop so i've never encountered it before. i hope one of you experts has dealt with this before
I don't have enough points yet to comment. My guess for #1 is either resolution or DPI differences between the 2 screens, and I don't have experience with the latter.
As for #2 and keeping the form aware of who called it, this is how I do it, which may not be the best solution, of course. ;)
First any form that can have multiple callers has a variable defined like
Dim callingForm As New Form
I typically create an Initialize routine to handle as much as possible before loading a form and this routine is called with the parent form (Me) as a parameter.
Dim frm As New frmClient
frm.Initialize(Me)
frm.Show()
Me.Hide()
In Initialize, callingForm is set to the parent
Public Sub Initialize(parent As Form)
callingForm = parent
'whatever else you need to do to init...
End Sub
Then when you exit the form...
Private Sub exitForm()
'whatever other closing stuff you need to do...
callingForm.Show()
Me.Close()
End Sub
That should get you started.
fyi for anyone encountering this problem, i solved it myself and it didn't require any coding. It was a difference between how vb apps act when the tablet is in "TABLET" mode, and when tablet mode is switched off. So all that needed doing is switching off enhanced tablet mode in the windows 10 settings
I have a WinForms application (VB.Net), where I have set ShowInTaskbar=False for all forms except the main form. This is because all other forms are dialog windows of some sort, and I did not want them to show up separately in the task bar.
What I see now is that when no dialog is open in my application and I use Alt+Tab keys to tab between currently open applications, I don't see a tile for my application. I do see a tile when there is a dialog open. This is very counter-intuitive to me.
As I said earlier, ShowInTaskbar property is true for my main form. What else is required? Thanks for your help!
After further research, I found that my problem was being caused due to having the form border as FixedToolWindow and ShowInTaskbar=False on the dialog windows. I changed the form border to FixedDialog, and set MaximizeButton=False, MinimizeButton=False. That fixed the issue.
I've got a complex form where some components are hidden until they are needed. I'd only got a few tooltips set (using the designer rather than doing it myself), but I noticed the other day that they had stopped working. Eventually I'd narrowed it down to some tooltips I'd got set on a tabpage that wasn't visible - If I made the tabpage visible then all the tooltips worked. I've worked round the problem by changing my form_Load code so that the tabpage is only made invisible (and removed from the tab control) right at the end of the form_Load code rather than at the beginning. This solution seems a bit clunky and might stop working if say the form load time changes or something.
Thanks
Kristian
My tooltips stopped working again after I added about 400 tooltips to a form. The tooltips loaded fine initially, but as I kept adding blocks of 100 (I have about 100 tooltip per tab page and may have say 20 tab pages). My fix for this was to create a new tooltip container for every tab page. The tooltip container is still created on the main form, but each tab page will use a different tooltip container.
Dim ToolTipPanel As ToolTip
ToolTipPanel = New System.Windows.Forms.ToolTip(Me.components)
I also set the tag property of the tooltip container to keep track of which one was which as I seemed unable to set the name property via code.
Let's start with a confession: I came from a VB6 background, and I'm accustomed to coding within the events of objects on a form, and as such my code for events ends up in somewhat random order in the code window. With this habit, it's never been very important to remember the names of controls (although I name them well)... I just double click on a button in the design view, which brings me straight to the code for that control's primary event. If I forget the name of a control, I click it and view properties. It's not a habit I've moved away from.
Well, now this is catching up to me. Using VS Express 2013, I have a form that contains a HUGE number of containers-within-containers, labels, buttons, and other doohickeys. I ported my code from VS.NET Express 2008 where this wasn't a problem. But now the act of selecting any control in the design view takes around 10 seconds before I can view its properties. If I drag to resize a control, and another 10 seconds passes before I can select another control. It makes designing this form nearly impractical.
In this particular project, I'm using use a tab control (which is never visible to the user) to design many "screens" which each contain panels full of controls. The panels for each "screen" are moved out of the tabs and docked into the main form as requested by the user changing screens. (I'm using the term "screen" to mean a window full of controls, usually maximized.)
Within the same project, a simple modal password-change form isn't slow to edit controls visually, even if the complex form is still visible in the IDE.
My question is in three parts:
First, what the heck is it spending all that time doing?
Second, is there a setting I can tweak to improve the speed?
Third, should I give up on trying to speed it up as-is, and move each "screen" into its own form for design purposes to avoid this slowness? (It's a lot of work to do that now... see next paragraph.)
Thus far I have avoided separating "screens" onto separate forms because I don't want a new window to come up when users change screens, and because code for the controls in one screen may affect the properties of controls on other screens... In such cases I prefer not to write out
form.doohickey.text = "blah"
..but rather keep it as ...
doohickey.text = "blah"
I'm using VB but I don't think this question is VB-specific.)
First off, I feel your pain. I have a management section of the application that I'm writing and I'm using a TabControl as well. I have 10 tabs so far and I've only added controls to about 4-5 tabs. I just added up the controls I have and there are about 360 controls so far on this one form and the designer file is ~3300 lines long. Currently anytime I change a property value of one of the controls or go to save the Designer, it takes about 3-4 seconds each time. I have a fairly decent machine; i5-3320M, 8GB RAM, intel 330 SSD, and it still takes a bit for it to do things within the tabControl. It also takes FOREVER to open and load the designer on that form...
What I've found is that it is easier to open a new instance of Visual Studio, create a test application, add a TabControl with the same properties, and design a new tab page from there. When I'm done I do a copy-paste into my actual project. This works great except for the few custom controls I've written in my main application project, I just have to sit and wait while adding them.
I'm now answering my own question. This is the approach I've ended up using, and it helps a lot...
My overall goal was to have an interface that didn't present a lot of windows, but still presented many different "screens".
I used to place all the different controls of different "screens" on separate panels, which were each contained in separate tabs of an invisible TabControl. I would then move those panels to my main form as needed by changing their Parent property of each panel as needed. The only problem with this is that the Winforms designer got ridiculously slow as the number of controls on a form increased into the hundreds.
Now, I am now designing each "screen" as a separate form, each of which contains a panel whose Dock property = Fill. Such a panel contains everything else on the form. The form itself never becomes visible.
As needed for to view various screens, I execute:
ScreenForm.Panel1.Parent = Mainform
...or, depending on how I lay it out...
ScreenForm.Panel1.Parent = Mainform.PanelXYZ
...I also either unload or hide any panels which already exist in the panel's new container.
I was GLADLY SURPRISED to find that the code for the various events of the controls contained in the panels would still run, because such code exists in the first form's file, not the displayed form's file. Luckily, it seems I was wrong. Event code follows the control itself. I can copy/paste not only controls, but also their corresponding event code to new forms for easier development and a faster Winforms designer.
All of this is similar to a MDI interface with maximized windows, but no title bar or [X] is displayed.
Essentially I'm doing everything as I did before, except using separate forms with panels instead of separate tabs with panels. The WinForms designer is much quicker because there aren't so many controls on any form.
I think I accidently found a workaround for saving a lot of time when changing the name of a control on a overpopulated container/project. Before you change the name, toggle False/True the "Generate Member" property of the control you want to rename(I believe you can also locate this under the "Name" property). This adds a few more clicks to the procedure but saves a lot of time. My not-yet-finished project has over 4000 controls and multiple forms and some of them are very "heavy" (10 - 20 seconds to normally change the name of a control). This, of course, don't help in anyway with the loading time of the project (about 35 seconds for me) but I can live with it. Let me know if this works for you too.
I'm making a custom control in VB.net 2008 Express. Without getting into the details, I am able to duplicate the issue as follows:
Make a blank custom control. Stick two textboxes on it. Don't add any code.
Run it and click the second textbox. (Don't click the first.) The text cursor appears of course.
Now Type... Although the text cursor moves within the second textbox, the text you type appears in the first textbox, not the second one.
I have found that this issue depends on the tab order of the controls. Whichever textbox is first in the tab order gets text typed in the other.
I have also found that if you press [Tab] to set focus on either textbox, the problem goes away.
QUESTIONS:
1) Is this a known bug in .net? (Specifically 2008 Express)
2) Will this phenomenon carry over when the custom control is brought into a larger project?
I followed the steps above and was able to reproduce it when I started with a Windows Form Control Library and ran it inside the UserControl TestContainer. I test this in Visual Studio 2008 Professional.
However, when I placed the user control inside a form in a separate Windows Forms Application project, the issue did not occur. So I'd think it's safe to say that this won't be an issue when the user control is used in another project.