I want to use UE4's comment function in the UI window of my personal project. It has been implemented to some extent, but there is a problem with Z-order. We put one Canvas and added a comment on it, but there is no problem setting the Z-order in the comment itself. When I put a new comment or something else on top of it, I want to set the Z-order of the title part of the comment and the box part below it differently.
Z-ordering of comments in any Blueprint is based on the order of creation.
Slate is slow enough, lets not try to add to the delay.
While the C++ code has a z-order argument, exposing it as a configurable object would add additional delays.
Design your code on paper first (as my first programming teacher taught me to do), then implement it.
Why should the existing code be modified to match your programming style?
Otherwise:
Simply delete all commented blocks and reorganize...
Related
How to model a toolbar ONCE and render it in some Parts/Views (not in the default place which is the window!)? Using the model level (and maybe Addons?)
I have currently
Eclipse 2022.03-4.23
Application.e4xmi with that Toolbar but
Gets added dynamically using an Addon that listens to "PART_ADDED" event topic which
Leads to a NPE due to other event topic "UIEvents.Part.TOPIC_TOOLBAR" within a framework method in a class called LazyStackRenderer
So the guy before me had written an Addon to dynamically add the Toolbar to the parts. Maybe to make the buttons save/print per part or because the main layout has two stacks and only the parts stack is relevant.
Appreciate any help! I searched a lot but no success!
I solved it so far. The dynamically created MParts were not added as children to the container (in my case the PartStack) in the first place and also had to comment the adding of placeholder objects that carry the same information of the parts. This dynamic step was done as a reaction to the topic #UIEventTopic(UIEvents.UILifeCycle.APP_STARTUP_COMPLETE) in some written Addon.
I am not a 100% sure that discarding the placeholders is safe but still this is the best trail I have ever reached.
I hope this would help others!
Thank you #greg-449
I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.
I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.
MSDN simply states that
If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.
MDN states
If a window does not have a parent, its parent property is a reference to itself.
And the W3 standard itself
The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document
I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?
So, why?
When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.
Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.
In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.
For instance, Bob is programming:
Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)
Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?
I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.
In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.
I hope I make some sense.
I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.
I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.
If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.
But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.
First of all drag and drop works correctly in my stages in version 4.3.0, so I just want to understand why I get the following problem with 4.3.3.
I have three stages. One sits in a container in a document in an iframe. The others sit in containers in the iframe's parent document, one displaying a complex layout of shapes and the other a single simple shape for testing. The document in the iframe which controls all the action has a viewfinder overlay that drags and drops correctly. However the shapes in the layout and test stages do not release on mouseup.
Any idea about what's going on would be appreciated ... I like to try and keep up to date.
Well, since I can't see any of your code I can only help so much, try doing the following.
For each shape that you have, add this attribute:
dragOnTop: false
example:
Kinetic.Rect({
fill: 'blue',
dragOnTop: false
});
Let me explain how I found an answer by first amending the structure. There is a holding file which contains shared files and two iframes - one for a machine-like index and one for a display each with its own scripts. The main shared file is nameset.json which lists all the objects and their key/value couplets. These are sent to 'fill out' the machine and display frameworks. I thought I could do the same with the Kinetic Global object, referring to the Global.stages array. It seems obvious now that each of the iframes needs its own Kinetic link (rather than pointer) and these need to be used to marry machine/display interactions like the map shown here. Anyway all the dragging and dropping works smoothly as promoted. Thanks for that!
Will mark as answered but if anyone has any comments would be pleased to read them.
I am trying to bring my secondary form to the Foreground, however when I do
MyForm.Show; // It may be hidden, therefore show it first
SetForegroundWindow(MyForm.Handle);
my Main Form appears aswell. The only way I can prevent that is to do MainForm.Hide; but I got to avoid that.
The idea is to have my secondary form appear on top of another application, without my Main Form having to do so as well.
If you consider to make another application for this functionality, then you may also consider the following compromise: minimize the MainForm to the taskbar (rather than hiding it) to prevent it popping up when activating another form.
If so, then try this answer. It does add an extra icon to your taskbar for the secondary form, but I guess that'll be no problem since a different application would either. However, if the MainForm is nót minimized but obfuscated by other windows, activating the secondary form wíll also popup the MainForm, just like you are experiencing now.
And for the completeness of this answer's sake, but not by any means meant as advice: this answer describes a (somewhat experimental) construction to make fully independent windows. The little time I tested that solution, it seemed to work, but be prepared not counting any longer on the full/default functionality of the VCL.
Try settings the state of the form to fsAlwaysOnTop.
I have a JFace TableViewer with an SWT Table, and I would like to custom render the content of some cells. I would like to use an SWT Control to render the cell content.
I would prefer to have only one instance of the Control doing the rendering, but if I have to instantiate one for each row, that would be acceptable.
Next, the solution MUST be compatible with the ContentProvider/LabelProvider approach (I am using EMF). This means that I cannot use the solution described in Sniplet 126 (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets).
Next, I though about using custom drawing. But here the catch is, that I have to send individual drawing operations to the graphics context. I was trying to have the Control render the content for me by calling redraw() or print(GC) upon SWT.PaintItem, but that just lead to uncontrollable flickering.
At this point, my best guess is to use SWT.PaintItem to do the drawing. This will result in duplicate code, as I already have a Control that can render the content the way I'd like it. I'd like to prevent this redundancy.
Any help is appreciated!
Well, after banging my head against a wall several times I made some progress. Specifically, I found this formu entry:
http://www.eclipsezone.com/eclipse/forums/t115489.html
It actually offers two solutions: The first solution actually uses widgets (not recommended due to performance, but I knew that before). I will try this out, and may post here how it goes.
The second solution suggests using StyledCellLabelProvider. I looked into this before, but it isn't powerful enough for my purposes. At least that's what I think right now.