I have the following problem:
I have a list of Components, that contain Rectangles with a width of either 200 or 800. I'd like to filter this list, and only create objects of the Rectangles with a width of 200 as I work on a small screen.
Preferably I do not want to create all objects, check their width, and destroy those with the wrong width again. For obvious reasons I really only want to create those with a width of 200.
To do this I would need to aquire knowledge of the width, before I instantiate them.
As far as I have seen, there is no publicly available and documented way of introspecting/reflecting the Component prior to it's instantiation.
My question is: Is there a non-public way to gain knowledge about what is packaged inside of my Component? Might it be possible with C++?
Or would it at least be possible to find out what kind of Object is encapsulated? Whether it will be a CustomComponent1, a Button, a RedRectangle...
Unfortunately not. You can't even predict it, since the Component could even point to a qml file that hasn't even been downloaded yet, if it was fetched from the network.
There are a couple of things you can try though, if you have room to approach the problem from another angle:
What you can do is pass properties from outside the component into it as it gets created. Assuming you control the code within the Component, you can then adjust how the internal elements get created based on the value of the property(ies) that was(were) set from outside.
If that's not good enough, say your Component provides multiple elements and you only want to create the ones that match your criteria (possibly a combination of many), then you can introduce a second Component layer within the first Component, and have that second Component either create the actual element if it matches your criteria, or an empty Item{} if it doesn't, which is as close as it gets to not creating anything.
I hope that helps!
Related
I'm a bit new to GMS2 and am having a bit of a problem.
In the current state of my game, you start in a useless room that only exists to initialize global variables and a persistent object. This room then switches to an actual level. All of this occurs in the creation code of the first room:
globalVars();
instance_create_depth(-2*global.tile_size, -2*global.tile_size, 0, OBJ_UTIL_manager);
room_goto(2);
Upon switching rooms, only some of the instances appear. In particular, only objects without a parent or with one certain parent appear. Objects with another type of parent do not appear. They are present in the room builder. They DO exist, but are invisible.
The same room, if moved to the top of the room queue and therefore being the first room created, works just fine as long as I add the above global variable initialization and manager object creation. Is there anything special that must be done when switching rooms to make things visible?
This is how the room appears in the editor: http://prntscr.com/lg2x3w
Compared to how it appears upon being switched to: http://prntscr.com/lg2wdg
I do not know the full detail of the problem, but I did have a similar issue, so I can tell you a solution without actually knowing what went wrong, but anyways hope it helps.
Firstly, use the instance_create_layer instead of instance_create_depth and make sure that these layers where you create your objects exist in both the first "fake" room and the actual room.
secondly, make sure you do not have any code that change the depth/layer in the create event. [again I do not know why this could cause an issue, but it did cause an issue to me, so maybe you have the same issue/solution]
As we know, when saving data in a redux store, it's supposed to be transformed into a normalized state. So embedded objects should be replaced by their ids and saved within a dedicated collection in the store.
I am wondering, if that also should be done if the relationship is a composition? That means, the embedded data isn't of any use outside of the parent object.
In my case the embedded objects are registrations, and the parent object is a (real life) event. Normalizing this data structure to me feels like a lot of boilerplate without any benefit.
State normalization is more than just how you access the data by traversing the object tree. It also has to do with how you observe the data.
Part of the reason for normalization is to avoid unnecessary change notifications. Objects are treated as immutable so when they change a new object is created so that a quick reference check can indicate if something in the object changed. If you nest objects and a child object changes then you should change the parent. If some code is observing the parent then it will get change notifications every time a child changes even though it might not care. So depending on your scenario you may end up with a bunch of unnecessary change notifications.
This is also partly why you see lists of entities broken out into an array of identifiers and a map of objects. In relation to change detection, this allows you to observe the list (whether items have been added or removed) without caring about changes to the entities themselves.
So it depends on your usage. Just be aware of the cost of observing and the impact your state shape has on that.
I don't agree that data is "supposed to be [normalized]". Normalizing is a useful structure for accessing the data, but you're the architect to make that decision.
In many cases, the data stored will be an application singleton and a descriptive key is more useful than forcing some kind of id.
In your case I wouldn't bother unless there is excessive data duplication, especially because your would have to then denormalize for the object to function properly.
I'm working on a graphical shape editor that uses the QGraphicsScene/QGraphicsView as its basis. I have a lot of experience with the scene/view framework and understand it fairly well. The issue that I'm having is that QGraphicsScene::items always returns items in the insertion order (either ascending or descending) regardless of the Z-order or the use of QGraphicsItem::stackBefore call.
The issue is that, as with most graphics editors, I need to be able to move shapes forward or backward in the stacking order. At the end, to save the resulting data, I have to traverse the list of the items in the scene and save each item's data in whatever format I'm using.
The only way that I've found to do this is that I have to remove items from the scene and reinsert them in the desired stacking order. In this particular task, it's a small number of items and happens without noticeable delay, but in a related editor, it could be many thousands.
While the QGraphicsItem::zValue and QGraphicsItem::stackBefore allow me to influence the drawing order, neither of them changes the order that gets returned from QGraphicsScene::items. Since the data I ultimately save needs to reflect the drawing order, I have to remove and reinsert to get the correct ordering at the end.
Questions:
Have I've overlooked any other techniques for managing items within the scene that will influence the results of QGraphicsItem::items?
Or is there another method for traversing the items within the scene that will give me the drawing order?
I can confirm that QGraphicsScene::items() and items(sortOrder) return the item list in the original creation and stacking order, which does not at all agree with the docs.
However, I found that by using
QGraphicsScene::items( QGraphicsScene::itemsBoundingRect, Qt::IntersectsItemBoundingRect, sortOrder) I do get the items in the correct drawing order, so this function apparently takes calls to QGraphicsItem::stackBefore() into account.
i don't use the z-order feature so I can't comment on whether that works in this scenario or not.
I have a table component, and each cell have to have a parsys (to allow authors to drop text, images, etc). That parsys must have a bespoke text component (in-house) within it as default.
In Sightly I've tried the following without results:
<sly data-sly-resource="${'table-col-header-{0}' # format=[column], resourceType='/libs/wcm/foundation/components/parsys'}">
<sly data-sly-resource="${'table-col-header-text-{0}' # format=[column], resourceType='/apps/componentlibrary/components/content/text'"/>
</sly>
Depending the actual limits in terms of rows/columns I would either opt for the cq:template node approach or an extension of the parsys which would include functionality to include pre-defined components. The OOTB parsys only includes what's pre-defined by templates (either page templates or component specific templates)
The cq:template node approach consists out of adding a node under the component definition which contains the structure it should have. This would allow you to predefine a text component (or other stuff) for each cell. But this would require finite limits on your rows and columns. If a component is added through the sidekick (and I believe the touchUI as well - but not 100% sure) it copies the whole structure of this node onto you're component location. Which in your case would mean that every single row/column would be copied and would result more nodes in the repo than you actually need (most of the time). This approach would be fine as long as the limits are rather low. Be aware that this approach does not work if you would include this 'table' component directly inside another component.
The second approach requires you to extend the parsys component to make it 'smarter' and provide 'default' items. This is more flexible, but also subjects to dealing with changes/enhancements that Adobe makes to that component.
As per the specification, data-sly-include should be used with a script.
Ok I have an object and a big square as well as other stuff in a room. I need the object which is obj_dot to randomly spawn but only within the big square (which is obj_paper) every time the room restarts.
Your question lacks detailed information on the setup of your sprites/objects, therefore this answer might not suit you 100% but hopefully it will provide you with a general idea of how to go about resolving this issue.
You probably want to put something like this within the create event for an object that is created on the room creation. I'm going to assume obj_paper is created on room creation (hence is recreated on room restart).
In the create event for obj_paper, type the following using GML.
//Assuming the sprite for obj_paper has it's x & y positioned in the center of the sprite
instance_create(irandom_range(x-sprite_width/2,x+sprite_width/2),irandom_range(y-sprite_height/2,y+sprite_width/2),obj_dot);
That should do the trick nicely.