NSBasic has upgraded and all-of-a-sudden the controls on my projects are all out-of-whack. It appears that the JQM ones are labeled as “obsolete” in the tool section, however I wouldn’t have expected a backward compatibility loss. Do I have to rework all my projects over this? In the screen shot those 4 text boxes at the top have always been at the bottom of this form and sized small. Can’t even move or resize them now. Was this break intentional?
I don’t make heavy use of NSBasic but I do have a couple of projects I do use and this breaks ‘em.
This same thing happened to me. All of my projects were broken, it did a number on my jqm elements. Same as yours above. So, I back tracked 8.5.0.1 and reloaded my project backup files. That seemed to work okay.
If this could be fixed, I would greatly appreciate it.
Here’s the current situation for me. When I originally updated to 8.5.2.1 on both my mac and windows I found the JQM Textbox problem. So, I downgraded to a previous version (on the mac is was 8.5.0.1 and all worked okay. Then I went on with my business until I saw this post.
You asked to see a ‘missed up’ project. So I upgraded to 8.5.2.1 again and then found the mac worked fine (what changed I don’t know). I also upgraded the windows to 8.5.2.1 and the problem appeared again. Oddly enough the textboxes are screwed up in the IDE but when the project is created to the local folder and run, the textboxes return to their proper position. I will send the zip file to you and will attach the screenshot of the IDE here.
Thanks. I’ve been able to reproduce the problem here.
I think it’s time to move away from jQuery Mobile. It is now almost 7 years since it was last updated. We’ve been calling it obsolete for several years as well.
I tried using the Framework Converter on your project. It did a pretty good job - you’ll have to do a bit of adjusting to the element sizes, but it seems to work right out of the box.
All of the JQM controls are simple to use and work really well. They really make a webapp for a phone look good. I like the Common controls as well, for they are simple to use. For special controls I use (and have a license for) jqWidgets. They are a bit of a pain to use, but, where else, can you get gauges and other special controls.
For me, Bootstrap controls are difficult to work with and they are time-consuming to get them to working right. Also, they usually don’t fit the theme of the JQM and Common controls. So, they stand out on the webapp as being different. I just haven’t had good luck using Bootstap controls.
I suppose the JQM controls may become (or are) a problem when building native apps for iPhone and Android using VoltBulder. I don’t really know for I don’t build native apps. I have a captive audience for my programs and my webapps work fine on any phone when placed on the desktop. Most of my users don’t know the difference. They do know that my webapps are very easy to place on the desktop and work just like a native app. Also, webapps are easy to put on windows and mac desktops as a shortcuts.
Progressive Web Apps are nice and I am thankful you guys have taken the time to include them in your software. I tell my people about them, but for the most part, it’s easier for them to place a shortcut on the desktop.
If you can keep JQM for webapp people like me, we would appreciate it. Using JQM and Common controls really makes developing webapps fun, quick and easy. Your software really does make it easy to develop programs for the web. NSB AppStudio has filled a big void in my software offerings. It’s opened many doors for me. Thanks.
Would there be any way, guys, that you could provide version 8.early for us to download somewhere so we don’t have to convert the projects? I have been told there is a conversion utility for them but even though the JQM and common controls are “obsolete” as far as the broader market is concerned, I’m with Rodney on this one. I’m not trying to keep up with the market, just maintain applications that are probably considered legacy at this point. I’d just like a copy of 8.2 (for Windows that is) that I can put “on ice” – and is there a way to turn off the nag screen that tells you it’s “out of date”?
That may not be the solution. The Design Screen uses the Microsoft browser engine to do its rendering, which has gone through some major changes recently. Once up a time, it used the IE 11 engine, then it went to the original Edge using IE11 emulation. Now it’s the new Edge, based on Webkit, with an IE11 emulation. It’s in those changes that the cause could lie in.
Let me say it again: it’s time to move away from jQM. It’s built around an old and insecure version of jQuery. jQM was never updated to use the newer version of jQuery. In the future, we could see browsers blocking the old jQuery based on security considerations, which would be immediately fatal for apps using jQM.
The Bootstrap controls are certainly more sophisticated than jQM. They’re built for the modern web and do a much better job on responsive apps.
I’ll see if I can find an older version of AppStudio to run some tests on, but seriously: it’s time to update your code.
I just tried 8.4.1 - it does not have the problem. This link should work for the next 24 hours to download it.
It looks like the change was introduced in AppStudio 8.5, when we updated the wxPython library. This solves a bunch of problems and is much needed update. However, it looks like it uses a different version of the browser engine.
Thanks, I’ll give it a whirl. Is there any way to turn off the startup nag screen to update? Not a big deal, I just dismiss it but since these projects are just being maintained not developed, I’ll just freeze the version there.
Appreciate that. If I was actively doing development on them, I’d agree, however they’re just in maintenance. If the emitted code stops working at some time in the future, I’ll just retire them, they’re strictly hobby projects for my own use. George just sent me a version that should still work; I’ll just freeze at that point.
Getting rid of the nag screen in 8.4.1 would require a new build of 8.4.1 - possibly introducing new problems. It doesn’t look like we can get rid of that nag screen.
That’s OK, no problem. Suggest, though, that you add a setting so the product can be set not to check for updates if a user desires that. A very common feature in commercial software.
