I would like to create a binding for the toplevel window state to execute commands if the window is in fullscreen mode (zoomed state) or not. I've been looking for how to do that, and I've come across this post: How to catch the maximize signal in Tk?
I'm essentially trying to do the same thing now. That question was posted 3 years ago, have there been any updates to allow Tk to deal with the maximize button? If not, could someone explain what the following code does?
bind $toplvl <Configure> {
if {"%W" eq [winfo toplevel "%W"]} {
ActOnResize %W %w %h [wm attributes %W -zoomed]
}
}
OK, let's look at the three “interesting” lines, one by one.
bind $toplvl <Configure> {
This attaches a binding to the <Configure> event to the binding tag in $toplvl, which I presume is the name of a toplevel widget. The <Configure> event is delivered when the size or position of a widget is changed (plus a few technical things that Tk doesn't really use).
if {"%W" eq [winfo toplevel "%W"]} {
First off, %W is replaced with the name of the widget that the event was dispatched to. This line makes what follows conditional on the event being delivered to an actual toplevel widget, which is useful because toplevels also receive events sent to all their children (great for binding hotkeys, not so great for other events).
ActOnResize %W %w %h [wm attributes %W -zoomed]
This calls the command ActOnResize, passing in four arguments: the (toplevel) widget name, the new width, the new height, and whether the toplevel is zoomed or not (which has to be retrieved with that call to wm attributes).
High Level Summary
Call ActOnResize whenever the toplevel changes size or is moved relative to its parent window (which is logically the desktop root), passing in its new size and a boolean that indicates if it's maximized.
Related
I want to do the following behavior in one delphi application.(10.3+)
I want a user to have the possibility to implement his own logical behavior of a program "saved in options".
Very similar with an arduino logical/program.
For example
I create a program that is keep tracking values about 10 heat sensors. But it can be anything.
The program has a timer and in the on timer event the following actions are taking places.
read the values from sensors
take action if needed
there are 2 types of info saved in this class.
Non Changing informations like ID name etc, and permanent changing (DATA).
here is the example of the base class that hold all the info from one sensor.
type TXXX = class
private
public
// info that are not changing ever
property ID : Integer ...
property SENSOR_NAME : String ...
// info that are constantly changing
property READ_TIMESTAMP : TDateTime ...
property CURRENT_VALUE : Double ...
property VALUE_SUPREMUM : Double ...
property VALUE_INFIMUM : Double ...
end
I need to create some sort of options of the program when a user can define his own logical that the program should respond if condition are meet.
for example a user want to say:
if CURRENT_VALUE > 5 and VALUE_INFIMUM > 0.5 then begin
"take action 1"
end
and so on...
"take action x" and all the actions are hardcoded. for example close/open a valve.
now these properties are more than 4 are like 50 or so.
anyone can point me some directions?
Regards
Razvan
There are 2 ways how you can solve your problem.
1st: You can use some of scripting engines. That’s the direct purpose of this components. You can use something like Pascal Script For Delphi (https://www.remobjects.com/ps.aspx), Fast script (https://www.fast-report.com/en/product/fast-script/), TMS Scripter (https://www.tmssoftware.com/site/scriptstudiopro.asp), etc.
2nd: If you have limited actions and condition – you can write your own parser and GUI for it for handle all this staff.
Make expressions parser, declare operants (numbers or allowed properties of your sensors, or other expression), declare mathematical operations (plus, mines...) and logical operation (Lower, higer, equal, and, not, or). It's can take a while to implement it, but you can build very user-friendly wizard to manage it.
If I implement a DoFn with access to the window, with the sidecondition that PCollection being transformed has already had some non-global windowing strategy applied to it, i.e. FixedWidows am I guaranteed to get an IntervalWindow?
For FixedWindows, yes. In general, no. The only general guarantee is that you'll get a BoundedWindow. Currently, all of the non-global windows provided by the SDK (FixedWindows, SlidingWindows, Sessions) use IntervalWindows. But it's perfectly legal to have a non-global windowing strategy that uses only BoundedWindows.
Yes. The window() method returns whatever kind of window the current WindowFn has placed the element into. So, with FixedWindows this will always return an IntervalWindow.
It will also always return a single window. So if you're using SlidingWindows and each element is placed into 5 different windows, then the processElement() of a DoFn annotated with RequiresWindowAccess will be called once for each window the element is placed into (so 5 times for each element).
I'm learning Dart by making a simple webapp. the app ui I have in mind has two parts, one is a control panel, the other is a workspace. by clicking buttons in the control panel, user should be able to control the workspace.
both the control panel and the workspace are custom polymer elements. In the Control Panel's dart class, I can access itself by using shadowRoot.querySelector, but since the control panel needs to control the workspace, I need to access the workspace also. but I don't know how to do that. I tried querySelector for example, It gave me null. I understand it is a shadow DOM in the workspace tag, but how to access other tags' shadow DOM?
I can't find anything online, every example and document seems to only use shadowRoot to access self elements.
It is difficult to access the shadow DOM of another element, and this is by design. Instead of having your two custom elements so tightly coupled, a better approach would be to use events or signals. Your control panel element should take user input and fire appropriate events using the convenient fire() method it inherits from the PolymerElement class. Your application can catch and then relay those events to your workspace element. If that seems overly circuitous, you can use Polymer's <core-signals> element to pass events without dealing with intermediaries.
As an example, inside your control panel element, you might have a bold button.
<button on-click="{{boldClicked}}">Bold</button>
When that button is clicked, the control panel's boldClicked() method is executed in response. It might look something like this:
void boldClicked(Event event, var detail, Element target) {
fire('core-signal', detail: {'name': 'bold', 'data': null});
}
Then in your workspace element's HTML file, you might have:
<core-signals on-core-signal-bold="{{boldEventReceived}}"></core-signals>
And finally, in your workspace element's Dart class would be a method like so:
void boldEventReceived(Event event, var detail, Element sender) {
// manipulate workspace shadow DOM here
}
This is just one of several ways to accomplish this. You can look over the Dart team's <core-signals> example for more.
And of course, if you're using Polymer to its full potential, you will find that you need to do very little manual DOM manipulation. Using data binding and data-driven views is a winning strategy.
You can either use a selector that pierces though all shadow boundaries querySelector('my-tag /deep/ some-element') or querySelector('* /deep/ some-element') or as selector that just pierces through one level of shadow boundary querySelector('my-tag::shadow some-element') or alternatively
place both elements within the <template> of another Polymer element then you can connect attributes of both components with the same field on the common parent element (this is the preferred method in Polymer.
The solution of #user3216897 is fine of course especially if the elements don't share a common parent.
Instead of shadowRoot.querySelector you should be able to use $['abc'] if the element has an id attribute with the value 'abc'.
I cant get my head around this. I was looking at the lynda.com ActionScript 3.0 in Flash Professional CS5 Essential Training. I understand all the other stuff, but this guy places a skater on the stage he has this code on the first frame on the main timeline:
import flash.display.MovieClip;
import flash.events.MouseEvent;
var boarder:MovieClip = boarder_mc;
boarder.stop();
boarder.x = 0;
boarder.y = 0;
boarder.addEventListener(MouseEvent.CLICK, clickedBoarder);
function clickedBoarder(evt:MouseEvent):void
{
boarder.gotoAndPlay(2);
}
function restart():void
{
boarder_mc.gotoAndStop(1);
boarder_mc.x = 0;
}
then on the skater he has a Display Object Container (Movie Clip) in it he has a Display Object a bitmap image of a skater and then an animation on the timeline in the skater where at the end the skater falls. On that last frame he has:
stop();
parent.restart();
He explains that this may not work and it doesnt he gets an error:
1061: Call to a possibly undefined method restart through a reference with static type flash.display:DisplayObjectContainer.
He explains that it knows there is a stop() function on the main timeline, and that it knows there is a restart function on the main timeline, but the datatype is different. He also says that the parent is the main timeline.
He says that we need to put Object(parent).restart();
My question is of what datatype and what is the main timeline (Movieclip, DisplayObject, Display Object Container)?
Why would it be a different datatype?
Thanks
The main timeline is a MovieClip, or if you have a DocumentClass, then probably a custom type that at least extends MovieClip.
However when you ask for "parent" of your skater MovieClip, you are really using the parent property that MovieClip inherits from DisplayObject (ActionScript Docs Here). This property returns the parent as type DisplayObjectContainer, regardless of the type that it actually is. Since it is the parent of a DisplayObject, it doesn't matter type it is it has to extend DisplayObjectContainer, so this is how it is returned.
So when you compile your ActionScript, the compiler looks at "parent" and sees it as type DisplayObjectContainer, looks at its definition of DisplayObjectContainer and errors because DisplayObjectContainer doesn't have a function called "restart".
What you said about the "stop" function is not really correct, since you are not calling stop on the main timeline, your are calling stop on the Skater's timeline. If you wanted to call stop on the main timeline you would need to call parent.stop(), and this would give you the same error, since DisplayObjectContainer doesn't have a method called stop.
These are both compiler errors, and are caused because the compiler is following a set of rules, and it can't make assumptions about what might actually happen when your program is running. It just knows that when you call parent.restart() it might receive a DisplayObjectContainer that won't have the method restart on it, and a run-time error will occur.
Now, by casting parent as type object, you are effectively telling that compiler that this thing can have any method or property on it, since Object is a dynamic class. So the compiler will now assume that you as the developer know that the method "restart" will exists on the "Object" that is given to that bit of code, and therefor will not error any more.
Thank you very much for you reply. This is really confusing. I thought that DisplayObjectContainer is a subclass of Display Object and it extends it? I know that Display Object Container is a Display Object and it can contain other Display objects and Display Object Containers. So the way I understand it, the maintimeline is a movieclip and therefore a DisplayObejctContainer, which can contain other Display objects (that you create in you application) and that is why parent returns Display Object Container, but that it is also a abstract class which means that it cannot have methods such as .restart and goToAndPlay() because it cannot actually be instantiated. However if its a MovieClip as you say then it can..... I dont get it.Does it mean that it is an abstract Class?
I have an Polymer.dart element with multiple attributes, e.g.
<code-mirror lines="{{lines}}" widgets="{{widgets}}">
</code-mirror>
on some occasions lines and widgets change simultaneously sometimes only widgets changes.
I would like to rerender component once independently on how many properties change in the same turn of event loop.
Is there a way a good built-in way to achieve that?
Additional trouble here is that interpretation of widgets depends on content of lines and ordering in which linesChanged and widgetsChanged callbacks arrive is browser dependent, e.g. on Firefox widgetsChanged arrives first before linesChanged and component enters inconsistent state if I do any state management in the linesChanged callback.
Right now I use an auxiliary class like this:
class Task {
final _callback;
var _task;
Task(this._callback);
schedule() {
if (_task == null) {
_task = new async.Timer(const Duration(milliseconds: 50), () {
_task = null;
_callback();
});
}
}
}
final renderTask = new Task(this._render);
linesChanged() => renderTask.schedule();
widgetsChanged() => renderTask.schedule();
but this looks pretty broken. Maybe my Polymer element is architectured incorrectly (i.e. I have two attributes with widgets depending on lines)?
*Changed methods are definitely the right way to approach the problem. However, you're trying to force synchronicity in an async delivery system. Generally we encourage folks to observe property changes and react to them and not rely on methods being called in a specific order.
One thing you could use is an observe block. In that way, you could define a single callback for the two properties and react accordingly:
http://www.polymer-project.org/docs/polymer/polymer.html#observeblock
Polymer's data binding system does the least amount of work possible to rerender DOM. With the addition of Object.observe(), it's even faster. I'd have to see more about your element to understand what needs rendering but you might be creating a premature optimization.
I think there are three possible solutions:
See this: http://jsbin.com/nilim/3/edit
Use an observe block with one callback for multiple attributes (the callback will only be called once)
Create an additional attribute (i.e. isRender) that is set by the other two attributes (lines and widgets). Add a ChangeWatcher (i.e. isRenderChanged() in which you call your expensive render method)
Specify a flag (i.e. autoUpdate) that can be set to true or false. When autoUpdate = false you have to call the render method manually. If it is set to true then render() will be called automatically.
The disadvantage of solution 1 is that you can only have one behavior for all observed attributes. Sometimes you want to do different things when you set a specific attribute (i.e. size) before you call render. That's not possible with solution 1.
I don't think there is a better way. You may omit the 50ms delay (just Timer.run(() {...});) as the job gets scheduled behind the ongoing property changes anyway (my experience, not 100% sure though)