I want to make other jump button in Construct Classic. But, as many people saying i need to use "simualte controls" action. But i can't find it. I tried to find it on many forums, googles, and nothing. I just can't
It should be something like this:
In this case my player has this properties, but the only important one is that it has platform behaviour:
To make the new jump first you need to create an event when you press the new key and then click "Add action", then select the object with platform behaviour (in my case "player") then
Related
TL;DR The title says it, details follow.
I'm having a form like
Bank: Bank of Neverland
Customer ID(?): Peter Pan
except for that it's real and the "Customer ID" is something provided by the bank. The bank may call it differently (so I change the label to e.g., "User name") and to prevent confusion, a lengthy hint may be needed. So I imagine using a question mark-like icon ((?)) popping the hint on click.
There are more fields which need a hint popup. I'd be fine with placing them elsewhere in the row.
However, the InputComponent.lbl is package-private and I can't see any way to attach the icon. I'm aware of TextComponent#hint(String hint), but it only allows for a rather short text, while we sometimes need a rather lengthy explanations (and that's not something we could change).
TL;DR we didn't implement that yet. Label is meant for the hint label not for that. You can probably add a ? button next to the component and show a popup or just add a label below.
What you are looking for is #1 in this image taken from here:
We implemented #2 which should make implementing #1 a bit easier... At least in theory but it won't adapt to the iOS mode of the UI which looks rather different. That was the main blocker for the implementation.
As a short term solution you can just add a SpanLabel below the text component or add a question mark button next to it.
Alternatively you can enhance the error label functionality in our code to support "helper text" which you might show as a popup on iOS or as a floating hint in the bottom of the screen there. Then submit that as a pull request to the project. You can also file an RFE we are under heavy workload so I'm not sure when we'll get around to it.
I need to modify the way the filter acts in the Silverlight Pivot viewer.
I have this filter:
Keywords:
x Keyword a
_ Keyword b
x Keyword c
_ Keyword d
_ Keyword e
The filter generates “Keyword a OR Keyword c”. What I need is “Keyword a AND Keyword c”.
Is that possible?
Any help is appreciated!
What Poker Villain says is quite right but that doesn't mean the PivotViewer is not a solution for you. I had a similar problem with a system I've been working on and managed to find a suitable way of making the PivotViewer play nice. This will only work for JIT collections though since it relies on re-fetching the data.
Essentially the system I've been working on is a case management system. Much of the data associated with a case is mutually exclusive and so fits the model of the PivotViewer but there is also the ability to add 'tags' to a case and like you suggest, often the user will want to combinational logic there. Here's what I did to fix the problem.
First off,..you're gonna want a copy of Silverlight Spy. Now in the explorer tab of SSpy, you can drill right down the Visual Tree and look at the guts of the PivotViewer. Here's how mine looks...
You can see I've drilled right down into the control named 'PART_FacetPane'. Below that there's a bunch of CustomAccordianItems. Essentially, you just need to subclass the PivotViewer (that's why mine says PivotViewerEx) and override the OnApplyTemplate method.
In here you will be able to use GetTemplateChild or some other means to navigate the VisualTree and add another control yourself. In my project, I used a simple tag cloud control I'd previously built.
What I do is handle the events of the tag cloud control and append querystring values to the URL used to build the CXML and filter the data based on these parameters. It's not as fluid as being able to filter the data 'live' as it were but it's a solution for now.
It's probably worth mentioning that depending on your circumstances, you may need to add a final, randomly generated querystring value to the CXML URL so you don't get a cached copy of the data.
HTH, Stimul8d.
bottom line ... NO.
You get what you get with this control. (for now)
but you could generate a "dummy" facet that was the concatenation of all the keywords for an item. But if you had more than a few keywords, it would look very ugly.
I'm thinking of CTR-Clicking each item to build up an array to add.... or even more fancy, drag select an area of items (don't think this is possible tho).
I'm aware of the custom events such as ItemDoubleClicked, but is there something like ItemSingleClick, where I can check if the CTR/SHIFT key is being pressed before executing an action.
I guess there is no possible way to customise the pivot since it is not open source... and the only method I can use is the doubleClick (plus match a keyboard key)...
I don't even like the way it zooms in right away after single clicking on an item.
I'm still open to suggestions (who knows... the pivot will probably still evolve), but otherwise, this thread I'm closing.
When designing a form I have the option of putting a close button at the bottom of the form. The form will also have a close form "x" button in the upper right corner of the window as provided by winforms.
Based on the principle of "There should be one and preferably only one obvious way to do it" I was thinking the close button should be removed because of the forms existing default functionality.
What have the rest of you found in your experience that works best for users or has been the standard for UI setup?
I have done a considerable amount of design work, and I can't say I have heard of the principle of, "There should be one way to do [some task]." In fact, I have heard (almost) the opposite: "There should always be one obvious way to do a task, but additional methods could be used to help different user types." An example of this is the ability to hit the "Save" button to save a document. But, you can also do "File > Save" and you can also hit Ctrl + S. Three ways to do the same task.
Also, if you're programming in a Windows environment (as it appears you are), you will automatically get multiple ways of closing a window. The [X], of course, Alt + F4 is typical, you can setup Ctrl + C, etc. I wouldn't particularly put a close button on the bottom of the form unless it flows with the form's input. For example, if you want to [Submit] or [Close] the form - does that make sense? Would it be better to [Submit] or [Cancel]? Think about what your users are doing and how they are using the form.
Here are some guidelines I follow:
If the form is an application (it was launched directly from Windows), it should probably not have a close button. Users expect to be able to close the application by clicking the X in the top-right corner.
If it is a dialog (it was launched from another window within your application) that simply displays information, it should probably have a close button and you can optionally leave the Windows close button as well.
If it is a dialog that allows the user to edit data it should have a Save or Apply button and a Cancel button but no Windows X. The reason is because it is ambiguous what it means. Should it save the data? Cancel it? Display a dialog asking them what they want to do?
In general I do agree that there should be only one way to do something. The reason is that a reasonable user will have to wonder if they do different things (even if they are named the same). Even if the user discovers they do similar things, they may wonder if they are subtly different.
Of course there are exceptions to the rule. For example, most users understand that the file menu, toolbar, and keyboard shortcuts of the same name all point to the same command.
I think that principle applies mostly to coding (and not for every language, think of Perl!), for UI's usually it's good to have different ways to do things... because it allows you to do things faster.
Think about any common operation like cut or paste, you can use the edit menu, the contextual menu, the keyboard shortcut or even the icons in the toolbar. Try to remove any of those ways of doing it in any application and you'll have hordes of users screaming to get it back.
So here the main principle is to not change what the user expects. Another remark: be consistent, though there might be different ways get access to the same functionality, all of them should work in the same way (I'd be very pissed of if copying with the keyboard shortcut did a different thing than copying with the right mouse button XD).
I have a single RoutedUICommand that can be accessed through various places in the UI. Such as global Keyboardshortcut, Menu, ContextMenu or Button. The code that is to be executed in the RoutedUICommand.CanExecute and RoutedUICommand.Execute methods depends on what UI element was used. How can I achieve this differentiation. I was thinking that I could use the (Can)ExecutedRoutedEventArgs.Source or OrigianlSource but the source is always the same. It is the main Root window. How is this usually achieved? What could I possibly be doing wrong?
If you need different code to run depending on the UI that invoked the command you are probably doing something wrong.
If you have something like a just doing something from a keystroke or opening a dialog asking for more information from a menu you should break this apart into two commands (like MS Office "Print" and "Quick Print" commands).
If you truly have to do different things from each UI element you are not getting any advantage from using commands and should think about using old fashioned event handlers, at least then the element specific code is tied to the element and not stored in a central all encompassing "Execute" code .
And if you choose to ignore my advice above, take a look at the CommandParameter property, you can set a different value fro the parameter for each UI element, at least with it you can keep an illusion of the UI/Logic separation commands are designed to provide.
Normally you could have different CommandBinding implementations for different 'Targets' - having different behavior for each 'Source' is unusual.
Could you give an example of what you are trying to do?