I’m trying to run this code via remote debug on a rMBP with a vmware fusion 6 client (windows 7) and I am getting a bluescreen each time. I still have to test it with a simpler app now.
I think enough people have had blue screen issues with this workaround, that it can be considered to not a viable solution. Your mileage may vary, but not a chance in the world I would include this in code that ended up on a customer’s machine.
It more or less warns about them
Right, but desperate times call for desperate measures. And Windows builds will make you try anything to try to deal with the flickering. MUCH more pronounced in the RS/Xojo builds than anything I produced under VB6 and both are Win32.
[quote=32891:@Brock Nash]I’m having the same issue. It is unfortunate because it does take care of the flicker all over the place when testing, but then I close a window and the CPU starts racing followed by the computer crashing. :-/
Alas…[/quote]Any chance you can supply a project example?
I’ve yet to have an issue myself (but my programs have been relatively simple) - I wouldn’t be surprised if some controls need to have their styles changed to make them compatible, which is something I was going to work on to make it a long-term solution…
However, I have stopped working on this method and started writing my own CrossPlatform GUI/ Windowing system API, but sadly, with Xojo trying to prevent that contractually in our terms plus no means of creating my own IDE that could write directly to Xojo’s compiler ( since they dont follow standard developer tool practices), it’s pretty much a waste of time
Plus the fact making an IDE for Xojo (IIRC) is against our terms, so simply put Xojo doesn’t want any competition I’ve decided over the last couple of days my time is better spent switching to C#
I’ve seen many VB6 apps flicker, just depends on what you’re doing. Our follie is having so many transparent controls at your disposal. The PagePanel, ContainerControl, Canvas, plug-in controls etc. It is still possible to reduce flicker of course, but does make it more challenging and annoying I agree.
You fiddle with it enough you can get it to look and work pretty normal. And when I say fiddle, I mean just throwing stuff at the wall and seeing what sticks. Use an Invalidate here, try a d Refresh (False) there, turn on Double buffer in this control, turn it off in another. Then you get things working fairly well, and the transparency issues rear their ugly head. I now there are standard practices that everyone says to do, I’ve read stuff on the forums dozens of times, but they don’t always work the same in each situation.
It is quite the challenge, but it is doable.
Yes after having to reduce flicker in the Windows IDE I understand your pains 
But the 2013r3 IDE does flicker less so I know it’s definitely doable.
[quote=33005:@Tony Stark]since they dont follow standard developer tool practices
[/quote]
Standards ? There are standards for this stuff ?
We dont have a command line compiler - hence you cant just shove code at it
I’ve seen Windows standard apps flicker (IE on Win 7 you can make flicker just by resizing the frame rapidly)
[quote=33047:@Norman Palardy]Standards ? There are standards for this stuff ?
We dont have a command line compiler - hence you cant just shove code at it[/quote]
while there isn’t a Set-standard in regards to Saying “thou must make thy Compiler external” its certainly Common practice and the key word here is “practice” not “standard” that you chose to focus on - when pretty much everyone (in terms of main tools in the industry) is doing it in one particular way, I believe that warrants the use of “standard”.
for the few compilers that are not accessible, typically the language and file / project format is well Standardized / specified
would love to see if xojo actually has Just one Specification of their own?
[quote=33052:@Tony Stark]while there isn’t a Set-standard in regards to Saying “thou must make thy Compiler external” its certainly Common practice and the key word here is “practice” not “standard” that you chose to focus on - when pretty much everyone (in terms of main tools in the industry) is doing it in one particular way, I believe that warrants the use of “standard”.
for the few compilers that are not accessible, typically the language and file / project format is well Standardized / specified
[/quote]
We’ve never really decided to do things based on “well everyone else does” - its really not a compelling argument
While we’d like to have a command line compiler for a number of reasons its just not been that high on the priority list.
And it’s not really crippled anyone so they cannot use the tools we do provide.
Yes its not as easy to create an automated build system (which is why we’d like one) - but its not impossible.
We have one it just requires a UI instead of just a console or headless machine.
But its largely automated.
Even if we did have a command line compiler you’d still have to have a license for thatIF/WHEN we get there.
Thats not really all that different from any other vendor who requires you to get a “license” of some kind (well if they sell a product they do).
VS requires a license to get the command line tools. Delphi is the same.
GCC and other free tools only require you to grab their toolchain (Xcode is a good example where you have to get Xcode to get the command line tools)
It’s our business - it’s how we make a living - so even if you did create an alternative IDE in some other language you’d still need a license from us to use the command line compiler IF / WHEN we create such a thing.
Having them & publishing them are not the same thing.
There isn’t a published one nor are we likely to publish one in the near term.
There’s little benefit to publishing one except maybe to enable competitors - which we really don’t see as good for our business.
So there isn’t one you can see.
But since you’re moving on to C# so why bother ?
[quote=33053:@Norman Palardy]We’ve never really decided to do things based on “well everyone else does” - its really not a compelling argument :P[/quote] It wasn’t an argument, just a point. What you have to ask yourself is “why is everyone doing it this way” and I’m sure there’s more than one legitimate reason even within the closed sourced proprietary solutions.
Although on that note:
Visual Basic → Real Basic
Visual Studio → Real Studio
Xcode → Xojo
[quote]While we’d like to have a command line compiler for a number of reasons its just not been that high on the priority list.
And it’s not really crippled anyone so they cannot use the tools we do provide.[/quote]Depends what your definition of cripple is especially with all the drama about lack of productivity.
Now lets say Xojo’s IDE is perfect but, some devs actually use more than one tool or language and quite a few use an IDE that integrates all of them together and they can properly streamline their product within their team. i.e. it’s not always about you /negative.
[quote]Even if we did have a command line compiler you’d still have to have a license for thatIF/WHEN we get there.
Thats not really all that different from any other vendor who requires you to get a “license” of some kind (well if they sell a product they do).[/quote] Well your IDE is free, so we currently Are paying for the compiler and framework in reality. If you want to charge an additional fee for a imposed software based limitation with no actual value added service that just reflects upon your business model.
MSBuild disagrees
http://msdn.microsoft.com/en-us/library/dd393574.aspx
Assuming they do have a more traditional command line support as well, I’m sure they are probably adding some value on top of that. That said, Sharp Develop seems to be using MSBuild to produce an executable from within it’s own IDE so I’m failing to see your point here.
Besides, why is this even being used as point of an argument? Thought you didn’t base your product on how other people do things?
[quote]But since you’re moving on to C# so why bother ? :P[/quote]Why bother? because prior to a couple of days ago I was still using Xojo and I was referring to a past tense? Past /Current Projects in Xojo + paid license etc. Moving doesnt mean overnight, neither does it mean indefinitely.
I Have to use VS now for my University course too. In addition, I probably would have written a language wrapper, Like Haxe > Xojo.
Just clicking maximize in the XJOJO IDE on my Win 8 i7 solid state computer takes 2-3 seconds for the controls to refresh and the window to redraw.<<
how many times is paint being called on the form?
when this happened to me, i found 40 paint calls
when a control was close to another, it can trigger a paint after painting itself.
I solved much of this by having a ‘I’m busy’ flag on the window, so that it only updated after the resize event had completed.
And moving the controls apart.
Norman and Tony, as has been pointed out to me a couple of times, the conversation is starting to diverge, please take the discussion on Build standards to another topic, this is thread is on Control flickering.
And previous to that I asked for a possible project example so I could look over it, as being the person who started this thread & solution which seemed to have went completely ignored.
I don’t think I saved anything, but my project was ridiculously small that caused it to Blue screen. I’ll look and see I saved it, but I think I deep-sixed it for fear of accidently running it in the future. I was very excited about the Declares initially because it was smoother, until I quit the app. I’ll see if I still have it.