I can share the code if needed but it felt like a lot to share to start, so I'll try to explain narratively. I am creating an interface to display network data (as you might have guessed from the title). My first issue has been going on for a few days where visIgraphLayout is not laying out my visual correctly. Regardless of using "full" or "square" as the "type", the network map extends beyond the edge of the display space. When I resize the interface window, then the map will snap to full. Why won't it simply resize automatically? If it matters, I do have the output space in a box element. Also, I have the layout styles working off radiobuttons, and when I switch between styles the map goes beyond the edges again.
Part 2 begins. While the above problem is annoying, it was livable. However, a new wrinkle popped up. I added some font size control to my visNodes code - i.e., radiobuttons set to switch between off (0), small (5), standard (14), and large (40) font size options. Once I implemented this code, when I resize the interface window, now the network map disappears completely after initial load. If I select a new label option, it will redraw but beyond the edges of the space.
All the issues resolve themselves if I ditch the visIgraphLayout, but then I lose the layout functionality which I really like.
I hope this is clear enough. I really appreciate any insights the community might provide. Be well.
I think I have figured out an answer. Long story short, certain pieces didn't work and play well with others. Went through and build it again, and all it good.
Cheers.
Related
I am creating an app for macOS using XIB and Swift, XCode 12.5. What I would like to achieve is a window with two NSTableViews side-by-side, having equal widths, filling the available space. A Stack View seems the obvious choice here.
I am easily able to use constraints to make a single NSTableView fill a window and resize correctly, but my difficulty is having two side-by-side NSTableViews. I've tried everything I can think of, but the symptom is always roughly the same: in Interface Builder, expanding the window, the NSTableViews grow (equally, correctly) but shrinking the window they remain at their previous maximum size.
Running this app gives a different result: the tables do actually resize correctly, but the cell sizes are out of whack. These tables are (should be) identical copies of one another: I literally copy-pasted the second one.
I have searched for information about using NSTableView inside Stack Views, but have come up empty-handed. I have probably overlooked something! I should add that I'm happy to move to Storyboard or even SwiftUI if it means being able to solve my problem, but it looks as if SwiftUI and NSTableView will complicate the matter.
I have tried to show my work here: https://github.com/toothbrush/tabletest2.
So everyone loves this new Layout semantics in storyboard, it's dynamic in a way it adapts at runtime when we're inside a UINavigationController for example.
Now what about inputViews? I know inputViews are NOT part of my view, but wouldn't it make sense to affect the bottom layout guide of the containing view when a keyboard is displayed?
I mean, I've seen several coding solutions to this issue, but only one affectively takes advantage of the bottom layout guide (the others are deprecated or plain simple wrong approaches), but even that one sounds hard-wacky-coding and naturally it doesn't animate.
Is there a way to tell the view to adjust the bottom layout guide for input views automatically? I mean in storyboard? or do we need to do this sucky code let every time we use a keyboard in our application?
If the Keyboard appearing animated:YES would affect the bottom layout guide in it's progress we'd have yet another apple-is-so-cool-they-make-all-the-hard-work-for-us-while-enforcing-their-user-interface-guidelines....aff that was long :)
Having recently switched to autolayout in Xcode 5 (and having watched the developer video from WWDC 13), I'm finding things to work pretty well with the exception of a View-Based NSOutlineView.
Before autolayout, this worked. Everything works fine and is in the right location, but now, specifically when I scroll, some of the new entries (and not all of them) end up in the wrong place, always larger and slightly higher.
The problem goes away once they are redrawn, but I don't understand the mechanic for drawing these NSTableCellViews and when they are created by the Outline View. I mean, it looks like they are created at some point, the program is guessing about the proper constraints, and then fixing them after a redraw.
It would be really nice to post an image to explain this, but can someone explain the life cycle of a view in an NSTableView or NSOutlineView?
I had to grapple with that issue myself and I was able to fix it today. This will happen if you are using any content inside an NSTableCellView that needs to be resized to fit into its cell or any subview of it. I fixed this problem by using an NSImage with the exact same size as a placeholder NSImage I added as subview to the NSTableCellView on IB. This resizing will break the constraints you added to or expect in this view.
I have a problem with redrawing in flex 4. I have a spark titleWindow, and if i drag it faster, it looks like it's mask is one frame late after the component.
it's easily visible with 1pixel thin border, because it becomes invisible even with slower movement.
You can try it here (what is not my page, but it's easier to show you here than uploading example):
http://flexponential.com/2010/01/10/resizable-titlewindow-in-flex-4/
If you move in direction up, you see disappearing top border. in another directions it's not that sensitive as it has wide shadow, and it's not very visible on shadow.
On my computer i see it on every spark TitleWindow i have found on google, although it's much less visible with less contrast skins, without borders or with shadows.
Do you see it there? i had never this problem with halo components. It's doing the same thing with different skins. I tried to delete masks from skin, cache component, skin even an application as bitmap with no success.
I also turned on redraw regions in flash player, and it looks like it's one frame late after titlewindow too.
Does anyone know why is it doing this or how can i prevent it?
Thank you
UPDATE:
no answers? really?
I have been facing the same problem and I was really pissed that I couldn't find any answer.
The problem with me was, that I tried to center the component "component.x = (parent.width - component.width) / 2" and then draw that component programatically. The problem was, that component.x is a Number which can lead to floating values like 10.5 or similar. And it looks like that bitmapFill function rounds floats DIFFERENTLY than drawRect function, which makes exactly the 1px line around the objects (but ONLY when parent.width is an odd number). Strange thing for me was, that I only called the Draw function once, but still this line keep recurring ...
Doing Math.floor(component.x) solved the issue.
P.S.: I think that you can also help your issue by setting cacheAsbitmap=true on the dragged object ...
Cheers,
Jan Prazma
I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.