When using WebView with Auto Layout in Lion, I get the following warning:
Layout still needs update after calling -[WebHTMLView layout].
WebHTMLView or one of its superclasses may have overridden
-layout without calling super. Or, something may have dirtied
layout in the middle of updating it. Both are programming errors in
Cocoa Autolayout. The former is pretty likely to arise if some
pre-Cocoa Autolayout class had a method called layout, but it should be fixed.
This thread explains why: Autolayout warning in Mac OS X
In Mountain Lion (MacBook Pro, 13-inch, mid-2009), the problem disappears—so why is it still happening on my Lion machine (Mac Pro1,1 2006)?
This is a annoying but benign log. It's unavoidable, but harmless, and it doesn't mean you're doing anything wrong.
Related
I have been trying for hours to solve this and have been searching for a similar issue like mine but none of the solutions I have tried works. I have a web application and added a user control:
<dx:Header runat="server" ID="HeaderControl" />
which I have referenced in web.config:
<controls>
<add src="~/UserControls/HeaderControl.ascx" tagName="Header" tagPrefix="dx"/>
</controls>
Everything works fine and it can build and run but there is that green wavy line and I get this warning:
Element 'Header' is not a known element. This can occur if there is a compilation error in the Web site, or the web.config file is missing.
I also found that this is because of the HTML 5 validation but I am lost now to fix this. I tried many things and don't know what else I can do to try and solve this. Please advice.
Ok, this issue been around - for 10, and probably 15+ years.
When you drag the control onto the web form - it sets up the correct reference.
OR YOU can do as your example - setup in web config.
Both should work - you are doing this 100% correct.
There are several tricks you can do to make this work.
I find it "difficult" since when in the forms desinger, or even the markup, then all of your simple (public) properites ARE supposed to show up in the property sheet -- BUT Again, this DOES NOT WORK.
So try this:
Change the build from x64 or ANY CPU to x86.
Then from build, you have 2 options:
Use the 2nd opiton:
Problem:
I OFTEN and in fact my case NEED and MUST and WILL deploy this build as x64 bits. I am using some library code and even some un-managed code - so I must and WILL deploy as x64 bits.
But, if I use x64 bits, then the property sheets and the markup "fail" as you note will occur!!!
However, I do find that in MOST cases (not all, but MOST) cases, if you do a re-build of the project to ANY CPU, then the green squggle goes away, and then the property sheet works.
So, say I have this user control on the page:
<uc1:UHotelEdit runat="server" ID="UHotelEdit"
MyTable ="tblHotelsA" />
In designer, we see this:
And if I try to display the property sheet, I get this:
So, try changing the build (config) to ANY CPU).
If ANY CPU does not work, then try x86.
So, this :
Then do a rebuild solution
You now get this:
Note the green squiggle is gone, and note how the property sheet works.
This can be a pain, since if your applicaiton MUST run and MUST deploy as x64 bits, then you have to CHANGE back to that before you re-compile and deploy (or publish).
In fact, once you do the above flip to ANY or x86?
You can now develop, and the property sheet for the UC works, and he green squiggle is gone.
and in fact you can EVEN flip the project back to x64 bits.
As long as you don't hit f5, or re-build, then at least you get a brief time of being able to use the property sheet.
But, once you hit f5, or re-build (and have flipped back to x64 bits), then after building, you are BACK to your issue/probelm (property sheet not working + green HTML markup warning squggle returns).
So, try ANY CPU. You may well find that this works, and often ANY CPU will, and often I find I can debug and develop the web applcation that way.
Then at deploy time I do always flip back to x64 bits.
So, it depends, and in some cases, you may well be just fine working with ANY CPU.
However, for vs 2022, then things are different.
So try the above tip, see if it works. (it not ideal).
And this issue?
Post here and other forums - going back for 12 and even more years!
this probem/issue is NOT new, and been around for a VERY long time.
The issue centers around some x32 bit code in VS and the desinger that NOT been upgraded to x64 bits.
I don't have vs2022 to try this out, but you MAY WELL find the REVERSE of above is required for this to work (since vs2022 is the FIRST version of vs that is x64 bits as opposed to x32 bits).
So do try ANY CPU. that often works.
but, if ANY CPU (and rebuld) does not work, then try as x86 - and rebuild and now the property sheet should work.
And you can even flip project back to x64 bits, but you lose the intel-sense, property sheet and green HTML markup warning WILL return after the NEXT build or even hitting f5 to run/debug.
I am working on Qt Quick [camera] application in jetson board. When I am launching and selecting camera from combobox for streaming in the application, It is throwing error
"QEGLPlatformContext::makeCurrent: eglError: 3009, this: 0x67d4d0"
Please help to fix this issue. Thanks in advance.
I encountered the same problem on my Jetson and made some investigation. Probably it had the same origin as yours. QEGLPlatformContext is always created with only support of EGL Window surfaces although its subclasses (at least QEGLXcbPlatformContext) may also use a EGL PBuffer surface. And actually this result in 3009 (EGL_BAD_MATCH) error when you try to bind the context with an offscreen (pbuffer) surface.
I've filed a bug where you can find the description of a dirty fix which helped me. It might help you also. On Ubuntu QEGLPlatformContext and QEGLPbuffer classes are part of libqt5gui5 package. Good luck!
I have been doing an implementation of Conways game of life in PySide [source]. So far it works good until a point in which, under certain conditions I havent figured out yet, the QGraphicsView i use to display the grid (which consists of several QGraphicsRectItems on a QGraphicsScene) suddenly stops being painted continuously. The rest of the window remains responsive and the game thread keeps running and signaling for the ui to update the current generation number. It is only when the window gains focus that the graphicsView updates for about a second and then freezes again.
I find this behavior particularly strange given that i dont override paintEvent, nor call repaint/update methods at all, but what the game thread does is to update every RectItem's brush color according to the status it should have every generation.
Any ideas on what could be causing this?
btw this is on Kubuntu 14.04.3 / KWin 4.11.11 / Qt 4.8.6
Managed to solved it myself! In case someone runs into same issue, all that i needed to do was to schedule an update by calling the update method of the qgraphicsscene every generation (i.e. after operating on the graphicRects from the game thread).
I assume the strange behavior was probably the result of trying to save cpu load, since for the gui thread there was no work to be done!
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
I'm compiling an .as file using fcsh, which uses it mxmlc.
I use the following shell:
mxmlc /Users/johannesjensen/Desktop/Doodler.as -static-link-runtime-shared-libraries=true
But when I get the .swf on my desktop it's dimensions are 500x375 and framerate is 24 when I told it that it needs to be 550x400 and framerate needs to be 120 using
[SWF(width="550", height="400", frameRate="120", backgroundColor="#FFFFFF")]
High framerate because it's a drawing app
Any ideas why it ignores the [SWF()] thing?
I'm using Flash Player 10.1 on a Mac OS X 10.6.4 Snow Leopard
A quick Google search reveals that the SWF Metadata tag need to be before the class definition, but after the imports. It sounds like you're putting it before the imports.
Source:
http://blog.madebyderek.com/archives/2007/01/12/as3-projects-and-the-swf-metadata-tag/
Keep in mind this is an undocumented metadata tag. I had never heard of it before now. So I can't guarantee that this information is accurate.