Current IDE Oddities and Obstacles

[richmond62]

You've been lucky.

Много смешно!

Well, let me see.

I "discovered" RR/LC in 2001 and have deployed various versions of it (from RR 1.1 to LC 9.6.2)
on approximately 20 Macintosh computers with 1, 2 or 3 monitors, and, since 2004 on approximately
40 PCs running a wide variety of Debian-derived Linux distros, and NEVER, NEVER had a problem.

I have also (in the last 7 years) seen LC working on various forms of Windows (XP to Windows 10) with various
multiple monitor configs with NO problems at all.

That doesn't seem like luck to me.

ALL the Mac/Linux computers I have run LC on have ONLY had Open-Source software or in-house (i.e. what the OS installs)
software installed.

[smelly]

richmond62: if you have used LC in a consistent manner with multiple monitors which manifests no display bugs, then I'm not surprised you get consistently good results. However, your apparent absence of evidence is not evidence of absence.

Re: "NEVER, NEVER . . . seen LC working on various forms of Windows (XP to Windows 10) with various multiple monitor configs [and 20 Macintosh computers] with NO problems at all"

Well then…you can see for your very first time in 20+ years, terribly distorted display problems with LC if you watch the videos I uploaded to YouTube. The URL is posted earlier in this thread by mwieder. These bugs are unique to LiveCode. None of the other hundreds of Mac applications I have used in many years have exhibited such gross anomalies. If you wish I'll upload to YouTube a plethora of common Mac applications running side by side with LC which do not exhibit such display disfiguring bugs.

The nature of software bugs is that 99 out of 100 people can run a program without the appearance of a particular bug. Yet due to some outlying factor of software and/or hardware configurations, one person can have a radically different experience due to to the software author's failure to follow OS guidelines.

For instance, how many programs do you see on Macs (unlike LC) that have a non-standard window affixed to the top of the screen just below the menu bar? I can't think of any. Has LiveCode followed Apple's developer guidelines with that Tool Bar? I don't see any window decorations on the Tool Bar window, hinting that it is a non-standard window. That might be a clue as to the source of the bug I experience.

Perhaps the LiveCode development team has not properly accounted for situations where the user switches the menu bar from one monitor to another while a portrait and landscape monitor are both employed, or perhaps when a variety of display Spaces (see the Mac Mission Control panel) are employed along with the above? Adjusting placement of that Tool Bar immediately under one (or both) of the menu bars according to such possible configurations must be a pretty complex coding solution—especially when using a non-standard window that I don't see other common Mac applications using.

[smelly]

Thanks for those details. Bug report numbers so we can follow the discussion?

I'm not inclined to file a bug report to LiveCode. I've learned how to workaround and live with the single monitor limitation of LiveCode. Frankly, I just don't have enough confidence that if I put in all the work necessary to document and explain the bug that it will be anything but a waste of my time and effort. The last time I filed a bug with LiveCode they could not replicate the bug and therefore confirm it. Nonetheless, after 100+ hours trying to overcome the bug in order to finish the iOS app I built, I finally figured out what the cause of it was myself. I never got any feedback from LC that they coded a solution to the bug, once I clearly identified the cause of it; which should have been a simple fix. My impression was that they just considered it a 'feature' and decided to rely on the LC coder to inform the app user how to avoid the weird non-standard 'feature' AKA 'bug'. Very disappointing. It makes one wonder whether investing 100s or 1000s of hours to develop LiveCode apps is going down a dead end street—just when you think you can complete an application you discover all your work comes to a dead end, since it can't really work as intended due to a bug or 'feature' limitation in the language.

[FourthWorld]

Most bug reports take less than five minutes to submit. Most of mine take about a minute.

If a bug is rare, dependent on highly-specific circumstances, and difficult to reproduce, it may take longer. But the upside there is that the bug's scope is likely limited to just a few users, possibly one, so not filing a report would have little or no impact on anyone else.

[smelly]

My previous experience with submitting an LC bug leads me to believe it will involve several detailed descriptions and back and forth communications over the course of weeks or months. I have no doubt there are simple bugs that are widely experienced by users which can take only a few minutes to elucidate. Not the one I experience in this case.

"so not filing a report would have little or no impact on anyone else". In other words..."screw you...the rest of us are doing just fine"—regardless if you paid $700+ for LC that doesn't work as expected. It should be of LC's own interest to discover if some number of initial users chose to not continue use of LC as a consequence of some bug rather than dismiss it as just not affecting most users, since few if any people report the bug.

The fact remains that no other apps on both of my Macs (iMac/Mojave & Mac Mini/High Sierra) using 4 different monitors, exhibit the display bugs I see, while simultanously running other common apps that don't. The evidence of this bug is illustrated on the YouTube videos I uploaded.

[FourthWorld]

"so not filing a report would have little or no impact on anyone else". In other words..."screw you...the rest of us are doing just fine"—

I did not write that last clause; those words are your own.

Whether you choose to take a moment away from posting about the bug here and post it in a bug report instead is up to you. We all get busy. No worries.

But if you feel the issue is worth addressing, I would encourage you to consider filing a report.

[jacque]

If you do decide to write a bug report, link to your videos and also this thread in the forums. That should lesson or remove all the back and forth you experienced before.

Note that a formal report is necessary for the team to track and fix a problem.

[smelly]

jacque,

Re: "link to your videos and also this thread in the forums."

Last time I tried to provide a link on this forum it did not appear. I was told I don't have the privilege to post links.

I'll try it again...here is the link to many YouTube videos illustrating a variety of LC bugs when using multiple monitors:

https://www.youtube.com/playlist?list=P ... ccbY7IBech

If the above link doesn't show up, you merely need to go to YouTube and search for "Livecode bugs playlist" and click on the link "LiveCode bugs and anomalies - YouTube".

FourthWorld,
Re: "I searched the bug DB for "multiple monitors" and even "multiple displays" - zero results. If the bug has been reported, sharing the URL or even just the bug report ID will allow us to get up to speed on the issue"

Something like half a dozen similar bugs have been reported to this forum regarding multiple monitors. Search for "Second monitor cripples LC" by dunbarx. In that dunbarx forum post you will see Martin Koob list 4 related multiple monitor reported bugs. This leads me to believe there are probably other reports of multiple monitor bugs in this LiveCode forum—wherever they may be hiding.

[rayjbenet]

This isn't a multiple monitors issue alone.

I'm on an M1 MBP 2020 (13"). BigSur 11.6.1

The revMenuBar stack opens at a topLeft of 0,184
The revTools stack opens at a topLeft of 0,84

It is a built-in retina display and the system settings are "Default for Display".

Unlike the problem with multiple monitors and selecting a "scaling" of the display, the buttons on those stacks are 'clickable' (i.e. the IDE receives the mouseClick at the actual location of the button).