Right, but you said “So far I can only get flicker with maximising & the inspector in general”, but I can see what looks like the same flicker I see when you grab the scroll bars as well. Just trying to confirm that you see it when you grab the scroll bars.
Yes, as in interacting with the inspector (such as scrolling) causes flicker. Which is in contrast to the control library that shares the same space but is able to scroll cleanly.
Making the issue two parts:
- The right side panel has an interaction issues with window resizing regardless of it being the library or inspector - the bottom panel seems to flicker on resize too.
- The inspector flickers for pretty much everything:
- When the window comes back into focus
- When the window goes out of focus
- When any popup window from the IDE appears (I guess this is related to focus i.e. #1 & #2)
- scrolling etc…
additionally the small buttons along the top of the window /code editor all flicker too under the same conditions as #2
buttons elsewhere seem to be fine (i.e. the options window) at least with gaining /losing focus.
OK, we are seeing the same thing.
Xojo, you need to address this somehow, even if means going back to the property list. This is just not acceptable in the Windows world, especially when you claim that “Xojo is written in Xojo”. If you are making that claim, then putting something out like this makes no sense, you just blew whatever marketing bump you got from the claim.
The issue is moving controls. If you move controls and you are using Win32 (which includes VB6 apps), they are going to flicker. I think Windows developers have grown accustomed to not moving controls to avoid the flicker. Temporarily (aka 1.1) we will probably just turn off smooth scrolling for Windows so that it doesn’t flicker. Longer term, we will find another solution.
[quote=10953:@Alwyn Bester]Then switching .Net would be a very welcomed move… especially if it resolves issues such as the flickering.
I was just stating my concerns with .Net, cause I had a few bad experiences with it back in the day (where I had to cut projects due to the logistical distribution problems the massive redistributable caused).
Never had such problems with Xojo for years now.[/quote]
The only part of our framework that would be in .NET would be the Windows desktop GUI part. The rest would continue to be in C++ and in either case, it would have no real impact on you as a developer. It would simply solve problems. And Wayne is correct: .NET is the Windows equivalent of Cocoa. It’s where all the new work is happening.
Can’t say I agree with your Geoff, my 3 products that I have been selling for 12 years are all writen in VB6…smooth as a baby’s bottom. The only flicker I have seen is in the grid control I use, it started flickering with Vista (under XP it was perfect), but it has a Redraw property that can be set to buffered, problem solved.
But none of this matters. If Xojo is going to .NET and it addresses the problem, it doesn’t break other things, and the resulting EXE is not dependent on the .NET Framework, I’m all for it.
When scrolling the list with controls, there is also a lot of flickering, at least at this laptop. Seems Xojo is slower than RealStudio
+1
no .NET please!
Do you move those controls? Are they on a scrolling surface?
Yes, but they are on top of frames that are housed in a 3rd party ActiveX Docking control, so maybe the OCX control provides some buffering on its on. So maybe the comparison is apples and oranges. And if I fart with RS long enough I can get it reasonably smooth, just takes time.
I really didn’t mean to beat this issue to death, it isn’t changing under WIN32. But I guess my point is, if you have something that flickers as badly as the Inspector does, it is probably best to find another way to display the options. If this was some part of hte IDE that didn’t get used much, it wouldn’t be a big deal, but because of it’s length, you constantly have to scroll it and you see the issue all the time. How about an option to display it as a list like you have the choice of with the Library?
You can bundle .NET in such a way that its not required to be installed.
The difficulty will be in that .NET is trivial to reverse engineer so your “GUI” code will be quite easy to access.
I second Melvyn’s last comment.
I don’t mind using .NET for the IDE as long as the executable is not tied to it. RS has been working fine in Windows 'till now, so I can’t see why we would need to deploy the apps now which required .NET - that, in the words of our biggest French customer would be a regression.
Right now I spend a lot of time dealing with Windows UI issues. It’s not what I consider time well spent. Having to place controls over rectangle objects, invalidate listbox cells, etc. just to make the UI look decent is a PITA. Window resizing is a complete mess( if anyone has any tips please pass them on). Also it’s not just moving controls, mousing over window frames and controls will show flicker by default.
If it was 2008 I would push back against .NET as the framework, but .NET is really present on just about everything Like the Move from carbon to Cocoa it seems like there may be some ancillary benefits to moving to .NET as well.
Regardless here’s the main point. XOJO is positioned as a easy/powerful dev platform, having to jump through a bunch of hoops to get a native feel(smooth non flickering) on windows is not really not what XOJO is about. Native controls are only a benefit if they behave like the native MODERN controls and WIN32 not cutting it at times( at least the way it’s implemented).
That said I’m a big fan of XOJO. Every few years I evaluate the competition but keep going back to REAL/XOJO, so I look forward to what changes may come. Keep up the great work guys.
I would have agreed with you in 2008; and I agree with you here as well. The more I think about it, the more I like the idea of making Xojo somehow compatible with .NET’s impressive runtime library. It comes with Window Vista, 7 and 8 by default, and is supported on all versions of Windows that Xojo officially supports. I would still be against it, however, if it meant the Xojo apps required .NET.
What I am finding, on Windows XP, is that the inspector does flicker really badly in the IDE, but only for some object types.
A quick check shows that it flickers badly for me on Windows, Textboxes and Checkboxes
It is quite OK with labels and containers.
I haven’t checked others.
[quote=19142:@Chris Carter]What I am finding, on Windows XP, is that the inspector does flicker really badly in the IDE, but only for some object types.
A quick check shows that it flickers badly for me on Windows, Textboxes and Checkboxes
It is quite OK with labels and containers.
I haven’t checked others.[/quote]
We have done work to reduce flicker on Windows for the next release, r2 which will be available later this month.
As i Posted before and posted an example of, 2 lines of code removes Control flicker and also fixes transparencies so they don’t keep artifacts from the previous position when moving controls.
[code]Soft Declare Function SetWindowLongW Lib “User32” (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
Soft Declare Function SetClassLongW Lib “User32” (hWnd as Integer, nIndex as Integer, dwNewLong as integer) as integer
dim Void as integer
Void = SetClassLongW (WindowHandle, -26, ctype(&h800, integer))
Void = SetWindowLongW (WindowHandle, -20, ctype(&h2000000, integer))[/code]
The problem is that you’re using basic window instancing code that was available to windows 98? instead of actually updating it with the extensions as windows evolved. At least so far I have not had a problem with ^
[quote=10923:@Alwyn Bester]I have my reservations when it comes to .NET.
One of the reasons I picked Xojo years back as a development tool, besides for it being one of the most convenient cross-platform tools, is that it produces compact binary applications that doesn’t require 100MB+ framework installs to go with it. [/quote]
.Net comes preinstalled an Windows since Vista
XP was the only one your installer may have had to install the frameworks on
For anyone who doesn’t want to play “hunt for constants on MSDN”, here’s what it boils down to:
SetClassLong(handle, GCL_STYLE, CS_SAVEBITS)
SetWindowLong(handle, GWL_EXSTYLE, WS_EX_COMPOSITED)
The documentation for CS_SAVEBITS says:
The IDE, and most dialogs, do not count as “small windows”. You can also read about what Microsoft employee Raymond Chen has to say in his What does CS_SAVEBITS? blog post.
As for WS_EX_COMPOSITED, it doesn’t really do anything under Vista+ due to DWM. Yes, I tested this in a C++ test app. Yes, it still flickers.
Here’s some more interesting things you can peruse at your leisure:
- Double buffering winAPI
- Mitigating Airspace Issues In WPF Applications (from Dwayne Need, a Microsoft employee working on WPF)
- Building a flicker free volume control (from Larry Osterman, a Microsoft employee)
And not directly related to flicker, but transparent control backgrounds:
- Why isn’t my transparent static control transparent? (from Raymond Chen)
- Like the cake, WS_EX_TRANSPARENT is a lie, or at least not the entire truth (from Raymond Chen, again)
I’m not saying it’s impossible to improve on our situation, since I’m not the Windows guru of the bunch. However, I am saying that it’s definitely not a two line fix that we’ve been ignoring for years on end.
[quote=19224:@Joe Ranieri]The IDE, and most dialogs, do not count as “small windows”. You can also read about what Microsoft employee Raymond Chen has to say in his What does CS_SAVEBITS? blog post[/quote]The main concern is RAM, and this article was written in 2006 when your typical computer would of had what, 512mb-1GB of ram shared with onboard graphics on the average computer at a much slower speed than today. I’m running with 16GB + 2GB video ram in 2013 -.-;;
Last time i checked, windows are stored on their own framebuffers in the GPU to prevent unnecessary paint events (such as when moving a window) so it’s actually unlikely to have any meaningful affect on any modern PC.
I added it to see if it would suppress the unnecessary firing of paint events xojo would do if you took the window out of the desktop area. In another thread where I originally posted it, you are aware it was posted for “trial”.
[quote]
As for WS_EX_COMPOSITED, it doesn’t really do anything under Vista+ due to DWM. Yes, I tested this in a C++ test app. Yes, it still flickers.[/quote]There are several instances where depending on your settings, composted is ignored regardless if you have it set.
I’m on windows 8 for the record.
[quote]I’m not saying it’s impossible to improve on our situation, since I’m not the Windows guru of the bunch. However, I am saying that it’s definitely not a two line fix that we’ve been ignoring for years on end.[/quote]This is much better solution than the 10+ years xojo has said “it’s the programmers fault for not properly double buffering and handling the paint events, not the xojo framework”