I'm working on an application using Java 3D on Windows. It works fine until the window (i.e frame) is moved to another screen/monitor. Then it starts behaving not normally even when I move it back to the first monitor.
The symptom is that the view disappears and reappears from time to time when resizing or moving the window. I only see the panel underneath then. It does not reappear until I click on it or resize or move the window.
Any idea why?
Thanks
I'm using java 3d 1.5, but the problem exists also in 1.6.
Related
Situation : Avalonia 0.10.18, Windows 11, 3 (same) monitors, NET6.0.
I have a 'main' window on the middle screen and I use a second (floating) window for some common values (with 'main' as parent). I save the position of the second 'floating' window on closing and on 'OnOpened' I read the values and position the window accordingly. That works fine as long as the floating window was not on the left monitor (negative X-value)(so all X-positions on middle and right work fine).
Since this second window has the main window as parent, the X-value is thus negative and I presume that is to prevent windows from being out of the screen area.
A last fact, but I doubt that that has to do with it, is that I'm using windowless windows, but the custom made positioning works correct in all cases (even on the left monitor).
Since in absolute values my 'floating' window is not out of the screen area and I do not know if I'm perhaps using a wrong event or is this rather a bug ?
OK, Sorry, my bad. I had in an upper class window a rule set that if the left < 0, not to use that value at the startup of the window.
So, it was a bug in my code and not in the Avalonia code !
I'm making a full screen application in visual basic and is having some issues with full screen and control resizing.
I've looked around both google, stack overflow and youtube for answers but none seems to be working for me. What I have worked my way to is that i need to use anchor or docking or something like that if I am not all incorrect
Edit:
Picture examples:
The main window in my editor.
When the program runs in maximized screen
Resolution of the program is 800x600 as its going to be made for a screen with that resolution.
You probably want to use anchor points. You can anchor a control to any side, all sides, or any combinations of sides in its container (the form, usually). When the form is resized, the control is automatically sized accordingly. You can also use the form's resize event and change the size or location of the controls manually when the form size changes.
I am using JEdit on two Ubuntu systems (12.4, 10.4) and having an issue with vertically-split window.
When I resize the whole JEdit window, two side-by-side split panes resize proportionally on one system (10.4) but on the other system the left pane stays a fixed size and all changes to overall window width get applied to only the right pane.
Both are JEdit v 4.4.2, both have only plugins: jdiff and buffertabs.
Is there a setting to turn weighting or proportional resize on?
Thanks!
UPDATE: This appears to be related to the JDiff plugin. The proportional resize stops working after you turn jdiff 'dual diff' on and then off. JDiff causes the panels to be set to equal sizes; when you turn off dual diff, the original proportions are restored but proportional resize is broken.
This indeed seems to be a bug in the JDiff plugin that changes some property of the SplitPane and doesn't restore it if there were splits before already. Maybe it shouldn't change that property after all, but use the same setting for proportional resizes. You should report this to the Plugin Bugs Tracker: https://sourceforge.net/tracker/?func=browse&group_id=588&atid=565475
As a work-around you can just unsplit and resplit the window, then the SplitPane is setup correctly again.
How do you host the PitchShift Audio Unit plugin correctly in its own window?
I am developing a Mac app that hosts Apple's system supplied Audio Unit plugins. With the new OSX 10.7 Lion, some of the plugins have updated views. PitchShift is one of these.
PitchShift and a few others have new knobs to change there parameters. When a knob is being turned with the mouse, a horizontal bar showing the knob's parameter value is displayed below the knob.
This bar stays on screen after the knob is released and even after the window is closed. If I click one of the knobs, thus creating a rogue value bar, and move the window the PitchShift view is in, the bar stays where the window used to be. And if I click the knob again at this point, a new bar appears, but both bars are actively updated with the changing knob parameter value information. This happens every time I repeat this process with more bars staying on screen.
After a few times with this happening, my app exits with bad access at NSApplicaionMain() call in the main.m file.
I checked in Logic 9, and this does not happen there. The bar seems to be tied directly to the knob, and thus disappears immediately after you let the knob go with the mouse.
I set the PitchSHift view to be the contentView of a dedicated NSWindow.
How is Logic keeping this from happening, or just how can I?
I've tried seeing if the parameter value bars where subviews of the PitchShift view, but they don't seem to be.
Any help would be greatly appreciated.
EDIT: When the a value bar first appears, I get the following output in the console from my program: Circle and line do not intersect
So I've found that it is using core-animations CALayers. The problem now is that the value bar layers aren't a part of the PitchShiftView's layer hierarchy. In other words, I can find all the other layers that build up the pitchShiftView, but not the layers for the value bars. Which seems like it might be the whole problem to begin with.
I finally figured it out. The parameter value bars are child windows of the window that owns the audio unit view.
To solve the problem, I catch the mouse up events for the window in my subclass of NSApplication, and I then close the child window (aka the value bar) so that they don't stay on screen.
This did not stop the exit bad access. I now think that is a separate issue that only appeared to be related to these lingering child windows.
I've created an application for Mac that uses a horizontal resize view (technically a BWToolkit resize view) that is linked to a toggleCollapse button. After collapsing and expanding the panel a few times, this happens (see image) right table-view should be flush with panel divider. Any one have any info on why this is happening. I've carefully adjusted my alignment and anchors to be correct but it seems like this is a weird issue that bugs out the view?
EDIT: Is anyone NOT having this issue? Any input would be helpful! Maybe I just need to start fresh?
This is a known bug in BWSplitView itself, and is related to how view animation and timers interact in that view. The details are covered here:
http://bwalkin.lighthouseapp.com/projects/36323/tickets/34-split-view-doesnt-resize-subview-properly-during-a-toggle-uncollapse-after-manual-collapse
Basically, before the view is animated, autoresizesSubviews is unset, so that the view can be collapsed/expanded without affecting the contents; a timer is then scheduled to restore the autoresizesSubviews property for when the animation has completed. But (of course) the animation may sometimes finish ever so slightly earlier, or later, than the scheduled timer fires; so autoresizing is switched on before the animation has completed, resulting in a few pixels resize. As you've probably seen, the subviews tend to move around a bit as the view is collapsed and uncollapsed.
The "full" fix for this would be to restore autoresizing when the CAAnimation has completed using a callback, but this hasn't been implemented yet. However, in that thread "Robert Payne" has posted a version of BWSplitView.m which uses a slightly different approach - the view sizes are recorded before collapsing, and restored after expanding. I applied this patch myself (I think it won't compile at first - but it's a simple matter of an undeclared variable?) and can confirm it does fix the problem.
Let me know if you'd like a BWSplitView.m which compiles successfully, or a copy of the compiled framework.