My Qt program (using qt v5.0.2) contains a QWebView in which the user is supposed to login using their email address and a password.
Everything works fine on Windows (tried on w7 and server 2008) but on Mac (10.7.5) I have encountered an annoying issue.
When pressing alt-2 (key combination for #) nothing happens.
I have spent countless hours testing and trying to find any info on the net about it, but I really can't find anything about it.
Is there any workaround? Fix? Or is this even a known issue?
Edit:
As noted in comments below, my keyboard is European/Swedish.
It's a genuine Qt Bug. I reported it as https://bugreports.qt-project.org/browse/QTBUG-34981
Today we found the code responsible for it in
./qtwebkit/Source/WebKit/qt/WebCoreSupport/EditorClientQt.cpp
Around line 480 it says
#ifndef Q_WS_MAC
// We need to exclude checking for Alt because it is just a different Shift
if (!kevent->altKey())
#endif
shouldInsertText = true;
Apparently, Q_WS_MAC isn't defined on Mac Builds at this time - I think it's been deprecated in favor of Q_OS_MAC.S
Simply changing the statement to
shouldInsertText = true;
when compiling on Mac fixed the problem for us.
Related
I have searched for a setting within the mvbasic extension within VSCode but I may have hit a dead end. I am new to using VSCode with the rocket mvbasic extension and still in the learning process, so please bear with me.
Our development for the most part has always been directly on the server using the editor within it to code and develop on a Unix/Aix platform with Unidata. Some of our code has array assignments with CHAR(253)/CHAR(254) characters within them. See the link to the image that shows how its done. Now I didn't do this code, the original software developer did this many many years ago and we just aren't going to go and change it all.
How code looks on actual server
The issue is when pulling the code to edit in VSCode, the extension is changing it, and I uploaded it back and didn't pay attention and it was implemented in our production incorrectly, which created a few bugs.
ALIST="H�V�P�R�M�D"
How code looks in VSCode
How code looks after uploaded back to server from VSCode
Easy to fix, no biggie, but now to my question.
Does anyone have this issue, or has a direction to point me into that maybe I need to create a setting to keep the characters in the correct ASCII format so that this doesn't happen again by mistake?
VSCode defaults to the sane choice for character encoding in 2022: utf-8, but sometimes you have to deal with legacy stuff.
https://code.visualstudio.com/docs/editor/codebasics#_file-encoding-support
If you click on the UTF-8 in the bottom right corner you can choose "Reopen with Encoding":
After that, you can select a different encoding. I chose DOS (CP437) at a guess and literal MV characters are displayed as superscript 2 (²), and for me I can save to the server and confirm those characters remain as #VM after a round trip (though for my terminal emulator they appear as } which is useful).
You can edit preferences and set "files.encoding": "cp437". One other thing that can be helpful if your programs don't have a standard extension (like .bas) as most don't is to set the default mode to basic so most of what you're editing will identify as MVbasic, and you can do a quick CTRL-K M to switch to any other modes if you're just pasting in something else like SQL.
Some useful links - the Rocket forums are helpful and the folks there are always super nice
https://community.rocketsoftware.com/forums/multivalue?CommunityKey=521bce2e-71d5-4d32-b560-dfa95e950eb5
The MV Extensions Community extension is a good group and always has been helpful when I've had issues. I've made some small contributions - they're very open. I prefer this extension, but honestly haven't done a deep comparison.
https://github.com/mvextensions
The CoreML couldn't be loaded. The first line is successful, but the second line gives an error called: The file couldn’t be saved.
The model does exist and modelUrl is correct.
The same issue is also found here
Unable to load CoreML model using MLModel.compileModel(at:)
Does someone know what the cause is?
var modelUrl = NSBundle.MainBundle.GetUrlForResource("SentimentPolarity", "mlmodel");
var compiledModelUrl = MLModel.CompileModel(modelUrl, out var error);
I found the answer just now. I encountered this problem when I deploy an app to an iphone from Mac in debug mode. Actually, there is nothing wrong with the code, it is something else. I did two things, first sign in to icloud(does icloud have anything to do with the iphone's provisioning profile for development?), secondly delete the app and re-deploy the app to the iphone. It solves the problem now.
Although I am not sure which one solves my problem, I assume it is the second thing I did. Let me know if anyone found the reason behind.
I am trying to show a progress in the taskbar of the plasma desktop using the KDE Frameworks. In short, it want to do the same thing as dolphin, when it copies files:
I'm kinda stuck, because I don't even know where to get started. The only thing I found that could be useful is KStatusBarJobTracker, but I don't know how to use it. I could not find any tutorials or examples how to do this.
So, after digging around, and thanks to the help of #leinir, I was able to find out the following:
Since Plasma 5.6 KDE supports the Unitiy DBus Launcher-API, which can be used, for example, to show progress
I found a post on AskUbuntu that explains how to use the API with Qt
The real problem is: This only works, if you have a valid desktop file in one of the standard locations! You need to pass the file as parameter of the DBus message to make it work.
Based on this information, I figured out how to use it and created a GitHub repository, that supports cross platform taskbar progress, and uses this API for the linux implementation.
However, here is how to do it anyways. It should work for KDE Plasma and the Unity desktop, maybe more (haven't tried any others):
Create a .desktop file for your application. For test purpose, this can be a "dummy" file, that could look like this:
[Desktop Entry]
Type=Application
Version=1.1
Name=MyApp
Exec=<path_to>/MyApp
Copy that file to ~/.local/share/applications/ (or wherever user specific desktop files go on your system)
In your code, all you need to do is execute the following code, to update the taskbar state:
auto message = QDBusMessage::createSignal(QStringLiteral("/com/example/MyApp"),
QStringLiteral("com.canonical.Unity.LauncherEntry"),
QStringLiteral("Update"));
//you don't always have to specify all parameters, just the ones you want to update
QVariantMap properties;
properties.insert(QStringLiteral("progress-visible"), true);// enable the progress
properties.insert(QStringLiteral("progress"), 0.5);// set the progress value (from 0.0 to 1.0)
properties.insert(QStringLiteral("count-visible"), true);// display the "counter badge"
properties.insert(QStringLiteral("count"), 42);// set the counter value
message << QStringLiteral("application://myapp.desktop") //assuming you named the desktop file "myapp.desktop"
<< properties;
QDBusConnection::sessionBus().send(message);
Compile and run your application. You don't have to start it via the desktop file, at least I did not need to. If you want to be sure your application is "connected" to that desktop file, just set a custom icon for the file. Your application should show that icon in the taskbar.
And thats basically it. Note: The system remembers the last state when restarting the application. Thus, you should reset all those parameters once when starting the application.
Right, so as it turns out you are right, there is not currently a tutorial for this. This reviewboard request, however, shows how it was implemented in KDevelop, and it should be possible for you to work it out through that :) https://git.reviewboard.kde.org/r/127050/
ps: that there is no tutorial now might be a nice way for you to hop in and help out, by writing a small, self contained tutorial for it... something i'm sure would be very much welcomed :)
On my touchscreen computer, I get a warning when I use a simple Qt combobox (in PySide):
class MyComBox(QtGui.QWidget):
def __init__(self):
QtGui.QWidget.__init__(self)
comboxText=["Hi", "Bye", "Give me a warning"]
self.comBox=QtGui.QComboBox(self)
self.comBox.addItems(comboxText)
self.comBox.move(20,40)
self.setGeometry(100, 100, 200, 100)
self.show()
When I create an instance of the GUI, the GUI looks as I expect, but when I press on the dropdown menu, I get the following warning in my shell:
QAccessibleWidget::rect: This implementation does not support subelements! (ID 1 unknown for QWidget)
While it is somewhat innocuous, I'd like to make this go away as it is distracting when it pops up every time someone clicks on a combobox. Google has not yielded much on the topic, except the following related discussion:
http://www.daz3d.com/forums/viewthread/6773/
I am on Windows 7 and Python 2.7, running under Anaconda. Note I am only getting this error on my Dell touchscreen laptop, but not my work desktops (neither of which are touch screen). All are Windows 7, but the touchscreen laptop is a Dell Inspiron 15z "downgraded" from Windows 8.
Because of the lack of people clamoring with me about this problem, it is clear this seems fairly localized to me. Hence I have submitted this as a bug report at the Qt Project site (https://bugreports.qt-project.org/browse/PYSIDE-242). I will update here if I hear anything back.
The thread http://niftools.sourceforge.net/forum/viewtopic.php?f=24&t=2147 indicates that it is a problem with Qt accessibility support on some touch/tablets. Can you try disabling the Tablet PC Components (or, in Vista, Tablet PC Optional Components) from Control Panel -> Program Features -> Turn Windows Features On or Off, as mentioned in the last post there and check if it works.
Also, if you just want to suppress the the warning, since it is innocuous, you can install your own message handler using QtCore.qInstallMsgHandler()
And, this is more likely a Qt issue than a PySide one.
I had the same problem on windows8. Stopping the service TabletInputService seemed to fix it for me
We're running on .NET 3.5 SP1.
Recently, in IE, some of our users started getting "Out of Memory" errors once in a while. This doesn't happen all the time. I managed to replicate it a couple times and I found that this code, from the AjaxControlToolkit.Common.Common.js file, was causing an infinite loop:
AjaxControlToolkit.TextBoxWrapper.registerClass('AjaxControlToolkit.TextBoxWrapper',
Sys.UI.Behavior);AjaxControlToolkit.TextBoxWrapper.validatorGetValue =
function(id) {
var control = $get(id);if (control && control.AjaxControlToolkitTextBoxWrapper)
{
return control.AjaxControlToolkitTextBoxWrapper.get_Value();}
return AjaxControlToolkit.TextBoxWrapper._originalValidatorGetValue(id);}
The last line (which calls _originalValidatorGetValue) basically calls back this exact function over and over because control.AjaxControlToolkitTextBoxWrapper is undefined.
The function defined right above it is AjaxControlToolkit.TextBoxWrapper.get_Wrapper(control) and could be use to create the wrapper if it doesn't exist, but I don't get the feeling I want to be changing the framework if I'm the only one who's seen this bug in the wild.
The bug does not always occur. It seems to occur when the first URL that is loaded contains an AJAX history point. If you open up a page and play with it, causing history points to be added, it works fine. But if you copy-paste the URL into another browser windows, you will get this problem.
Therefore, my guess is I am doing something wrong with the history control that doesn't setup the wrappers properly. Even so, there appears to be an infinite loop in there.
Any ideas/clues?
I filled out a bug report on Microsoft Connect. While filling it out and testing various scenarios, I noticed it was working fine locally but not remotely. Comparing my production/development environment, I noticed CombineScripts was false locally. Deploying that to my production server seems to have resolved the issue.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=373171
If you remove LoadScriptsBeforeUI='false' from ScriptManager, this problem is solved.
You might want to post a bug report on Microsoft Connect.