I try to write small GUI programm for windows using wx and wxFrame. I have this code in ctor:
MainFrame::MainFrame(wxPoint pos)
: wxFrame(NULL, wxID_ANY, wxT("Sample text"), pos,
wxDefaultSize, wxBORDER_NONE | wxFRAME_NOTASKBAR)
{
SetSize(wxSize(250, 100));
CreateLayout();
}
And CreateLayout function:
void MainFrame::CreateLayout()
{
wxBoxSizer* sizer = new wxBoxSizer(wxHORIZONTAL);
sizer->Add(new wxStaticText(this, -1, "1000.56"), 0, wxLEFT|wxALIGN_CENTER_VERTICAL, 5);
SetSizer(sizer);
}
As you can see, I want to align text to vertical center of the frame. But with this set of frame style flags sizers doesn't work! They work only if i set wxDEFAULT_FRAME_STYLE! But i need to have frame without borders and capture and close|minimize|maximize buttons, how can I get this work?
In the MainFrame constructor, move the call to SetSize() after the call to CreateLayout(). That's it.
Normally, the call to Show() after creating the frame should make the above unnecessary, but it looks like in this case it doesn't (see the details below). Anyway, I think it makes sense to first set up all the sizers and controls inside the window, and then change the size to trigger a Layout(), just to be on the safe side.
This also means an alternative solution is to leave the call to SetSize() where it is, and force a layout by adding a call to Layout() at the very end of your CreateLayout(). But... I like being efficient (read: lazy); I'd go with the first solution.
EDIT: I've found some information regarding why this happens.
For a wxFrame created with wxDEFAULT_FRAME_STYLE, the call to Show() ends up calling ::ShowWindow(), which triggers a WM_SIZE, which eventually triggers a Layout().
For a wxFrame created with wxBORDER_NONE, ::ShowWindow() doesn't seem to trigger a WM_SIZE, which is why the solutions above for forcing the call to Layout() are necessary.
Related
Right now I'm using wxWidgets msw 3.0.5 on Windows 7 and the xrc file was created with wxFormBuilder 3.10.1
Normally I use something like this to avoid my wxframe be resized smaller than my child controls:
MyFrame::MyFrame() : wxFrame( NULL, wxID_ANY, wxT("Sometitle") )
{
wxBoxSizer* frameSizer = new wxBoxSizer( wxVERTICAL );
wxPanel* panel = new wxPanel( this, wxID_ANY );
// ..
frameSizer->Add( panel, 1, wxEXPAND | wxALL, 0 );
SetSizerAndFit( frameSizer );
Centre();
}
But, when I'm use xrc file to load my frame I using like this:
MyFrame::MyFrame()
{
// used in App::OnInit()
// wxXmlResource::Get()->InitAllHandlers();
// wxXmlResource::Get()->Load( wxT("some.xrc" ) );
wxXmlResource::Get()->LoadFrame( this, NULL, wxT("MyFrame") );
// ...
Fit(); // this resize my frame to show my child controls as expected (like SetSizerAndFit does )
SetMinClientSize(GetSize()); // is this the right way?
Centre();
}
Fit() resize my frame same as SetSizerAndFit, but if don't use SetMinClientSize my frame can be horrible resize shriking and hiden my controls. So my questions are:
Is there a feature that I'm missing in wxFormBuilder to avoid resize less the frame child controls?
Using SetMinClientSize is the right way?
Is there are any other ways in xrc file to have the same effect like SetSizerAndFit?
Thanks.
Note: this happens also in my linux wxwidgets library
The names are unfortunately confusing, but SetSizerAndFit() calls SetSizer() and wxSizer::SetSizeHints(), and not wxWindow::Fit() as might be expected. So to have exactly the same behaviour as in the first case you need to call GetSizer()->SetSizeHints(this) in your frame code.
And, FWIW, wxSizer::SetSizeHints() does something sensibly equivalent to
wxSize size = GetBestClientSize();
SetMinClientSize(size);
SetClientSize(size);
i.e. it sets both the current and min sizes, which is what you presumably want.
Following the example on the website: https://vega.github.io/editor/#/examples/vega-lite/interactive_bar_select_highlight
I want to programmatically set the selections via signals. I realize that I could emulate a click by doing the following
VEGA_DEBUG.view.signal("select_tuple", {"unit":"","fields":[{"type":"E","field":"_vgsid_"}],"values":[1]})
However, I cannot proceed to select another, e.g., the shift select of the 2
VEGA_DEBUG.view.signal("select_tuple", {"unit":"","fields":[{"type":"E","field":"_vgsid_"}],"values":[2]})
This makes sense, since only shift-click accumulates the state.
I tried modifying the accumulated signal
VEGA_DEBUG.view.signal("select", {"_vgsid_":[1,2],"vlMulti":{"or":[{"_vgsid_":1},{"_vgsid_":2}]}})
However, this does not help. Is this not possible? I understand that a custom solution may be possible in hand-rolled vega, as opposed to that compiled from vega-lite.
Thanks.
Just need to set VEGA_DEBUG.view.signal("select_toggle", true) before adding the new select!!
After much research I made this example of how to change the vega-lite brush programmatically
https://observablehq.com/#john-guerra/update-vega-lite-brush-programmatically
Using #koaning example this stack overflow question I figured that you can change the brush by updating "brush_y" (assuming that your selection is called brush) or change the selection using "brush_tuple" (which doesn't seem to update the brush mark)
viewof chart = {
const brush = vl.selectInterval("brush").encodings("y");
const base = vl
.markBar()
.select(brush)
.encode(
vl.x().count(),
vl.y().fieldQ("Horsepower"),
vl.color().if(brush, vl.value("steelblue")).value("gray")
)
.height(maxY);
return base.data(data).render();
}
update = {
// From https://codepen.io/keckelt/pen/bGNQPYq?editors=1111
// brush_y -> brush_tuple -> brush
// Updates on pixels
chart.signal("brush_y", [by0, maxY / 2]);
await chart.runAsync();
}
Crossposting here in case it might be useful for anyone
I have an object I want to drag around the screen with the mouse in Processing. I set acquired to true on mouse down over the object, and to false on mouse up, thus:
void mousePressed() {
if (overThing()) {
acquired = true;
}
}
void mouseReleased() {
acquired = false;
}
I then query acquired in my update(), and drag the object if it is true.
void update() {
\\ other stuff...
if (acquired) {
\\ drag thing code ...
}
}
This all works fine in Processing. mouseReleased() gets called whether I release the mouse inside or outside the active window.
However, when I move the code to Chrome, using processing.js (v1.4.8), mouseReleased() is not called if I release the mouse outside the canvas (whether the mouse is still over the web page, or outside the browser window). So when I return the (now unclicked) mouse to the canvas, the object is still getting dragged around.
I tried including a test of mousePressed in update(), but that also returns true in these circumstances.
Any help on what I need to do to make mouse state changes outside the canvas visible with processing.js?
I don't know about Processing specifically, but releasing mouse buttons outside a widget is a common issue in GUI development.
I suspect that you have no way of knowing the precise time when the mouse is released outside the widget, but you do have two options:
Set acquired = false in mouseOut(), as #Kevin suggests.
I assume there is some type of mouseEntered() method in Processing, and also some way of knowing if the mouse button is currently pressed (either a global variable, or an event object passed to mouseEntered()). You can catch the mouse entered event, check if the mouse has been released, and set acquired = false then.
Like so:
void mouseEntered() {
if (mouse button is pressed) {
acquired = false;
}
}
Edit: From your comments, #Susan, it seems like there is a bug in processing.js, where mousePressed is not set to false if the mouse button is released outside the canvas. One thing pointing to this being a bug is that the mouse movement example on the processing website also shows this behaviour.
Depending upon how much control you have over the website this is going on, and how much effort you want to go to, you could fix the bug yourself by writing some javascript (separate from your processing code):
Define a mouseUp() event on the page <body>, to catch all mouse release events on the page.
In the mouseUp() event, check if the event comes from your Processing control. (There is probably an event object passed to the mouseUp() function, and you might have to give your Processing control an ID to identify it)
If the event doesn't come from your Processing control, then fire a mouseUp event yourself, on the Processing control. This should (hopefully!) trigger a mouse event inside your Processing code.
I'm not sure what Processing will make of the mouse (x,y) position being outside its control when it handles the event you send it. You might want to set a flag on the event object (assuming you can add extra data to the event object) to say "don't use the (x,y) position of this event - it's outside the control".
Edit2: It was easier than I thought! Here is the JavaScript code to detect the mouse being released outside of the Processing canvas and send the mouseReleased event to the canvas. I've tested it on the mouse movement example from the Processing website, and it fixes the bug.
It uses jQuery (although it could be re-written to not use jQuery), and it assumes your Processing canvas has the ID "processingCanvas":
$(':not(processingCanvas)').mouseup(function(){
Processing.getInstanceById('processingCanvas').mouseReleased();
});
To use this code, include it anywhere in your page (in a JavaScript file or in <script> tags) and make sure you have the jQuery library included before this code.
The Processing object allows JavaScript to call any functions defined in your Processing code. Here I've used it to call Processing's built in mouseReleased() function, but if you wanted to call a custom function to handle the mouse-released-outside state differently, then you could.
You should use the mouseOut() function to detect when the mouse leaves the sketch:
void mouseOut() {
acquired = false;
}
More info in the reference here.
I'm new here!
I searched internet a lot for my question, but I didn't found anything - or I'm really thinking wrong.
I program on VB.NET since 2 years, and on XNA since 6 months. I built a game and an editor for the game, and they are running great.
The question i about my editor (for an RPG game), and I'll try to explain at my best.
I have a main form with menustrips on top and a big picturebox covering the entire form, a picbox that is binded to the Game1 object when it start with the command Run().
The Game1 object handles two classes, that are basically panels that it draws on the picbox of the main form: a tileset panel in the left down the tabpage, and a map panel on the right. This works perfectly.
The problem is when for the first time yesterday I tried to draw with XNA on a form. I have multiple forms to manage NPCs, equipment, conditions, events, variables, etc and in the event form, I have a tabpage that manages map teleport events. On this tabpage I have a list of maps and a picbox where I want to draw a small view of the selected map. For this, I created of course a minimap panel with it's own draw and update methods.
...but of course, the minimap appears on the main form on the normal map.
I tried to change in real time the DeviceWindowHandle, but I failed... apparently, it changes only during the Run()
I tried to create a new game object and binding him to the event teleport form, but in the moment of lunching the Run() of this object, the debugger stops saying that I cannot launch more that one game loop in a thread.
I can't believe that XNA doesn't let to draw multiple things on different forms... and I can not pause the main loop from the event form (which is called from the NPC form) to start the minimap loop!
I think that is something really easy that unfortunately I don't know...
I'm getting crazy and lost... what I can do?
Please help me, thanks!!
Here's an example of what I commented (Sorry it's in C# but I don't really write VB.Net. Translating it should be pretty straight forward though):
private MainGame mainGame;
private ToolboxGame toolbox1;
private ToolboxGame toolbox2;
// And this should be put in some Form Initialization method:
Task.Factory.StartNew(() => {
this.mainGame = new MainGame(imgEditorPictureBox.Handle)
this.mainGame.Run();
}
Task.Factory.StartNew(() => {
this.toolbox1 = new ToolboxGame(toolbox1PictureBox.Handle)
this.toolbox1.Run();
}
Task.Factory.StartNew(() => {
this.toolbox2 = new ToolboxGame(toolbox2PictureBox.Handle)
this.toolbox2.Run();
}
Something like that should do it. Obviously whenever you "move" variables from one "game" to another, keep in mind that they run on different threads, so anywhere you use it, you'll need to
lock (dummyObject)
{
// Use data
}
to make sure you're not accessing it in one game, while the other is trying to set it.
Locking in VB.Net: Is there a lock statement in VB.NET?
You'll obviously need to come up with some smart infrastructure to get this working smoothly, but since you've made a game and editor before, I'm sure this should not prove a humongous challenge.
All you want show to the player you need draw in the game window. You have one Game with one GraphicsDevice and by default all you draw will be rendered on the game window. But you can call GraphicsDevice.SetRenderTarget method to change render target. Call it with RenderTarget2D object as parameter and anithing you will draw after this will be rendered to that render target.
Next you need call GraphicsDevice.SetRenderTarget(null) to set game window as render target again.
There is my (uncompleted yet) custom GUI realization for XNA. I hope it can help you.
Update
class Game1 : Game
{
GraphicsDevice graphicsDevice;
SpriteBatch spriteBatch;
public RenderTarget2D MinimapRenderBuffer;
public RenderTarget2D AnotherRenderBuffer1;
public RenderTarget2D AnotherRenderBuffer2;
public EventHandler RenderBuffersUpdated;
void Initialize()
{
// Better initialize them only once, don't do it in Draw method
this.MinimapRenderBuffer = new RenderTarget2D(this.graphicsDevice, 100, 100); // any size you want
this.AnotherRenderBuffer1 = new RenderTarget2D(this.graphicsDevice, 50, 50);
this.AnotherRenderBuffer2 = new RenderTarget2D(this.graphicsDevice, 500, 500);
}
void Draw()
{
this.graphicsDevice.SetRenderTarget(this.MinimapRenderBuffer);
// draw minimap to MinimapRenderBuffer
this.graphicsDevice.SetRenderTarget(this.AnotherRenderBuffer1);
// draw whatewer to AnotherRenderBuffer1
this.graphicsDevice.SetRenderTarget(this.AnotherRenderBuffer2);
// draw whatewer to AnotherRenderBuffer2
this.graphicsDevice.SetRenderTarget(null);
// now draw to screen
if (this.RenderBuffersUpdated != null)
{
RenderBuffersUpdated(null, null);
}
}
}
And use rendertargets in your editor when event raised. And you can convert them to bitmaps.
I have a flyout that appears near the cursor when a particular user input is triggered.
According to the docs, the Flyout.Placement property is only a preference and does not necessarily reflect the position of the flyout.
I expect the framework to call GetFlyoutPlacement to determine the actual placement. I want to know what the actual placement is so that I can add a little arrow pointing at the cursor position, something like shown in the following:
Is my only option to make the call to GetFlyoutPlacement myself (triggered on the Flyout.Opening event), or is there some more convenient way to do this?
My calls on GetFlyoutPlacement and GetFlyoutPlacementTargetInfo resulted in Error HRESULT E_FAIL has been returned from a call to a COM component. which didn't leave me very much to go on, so I just ended up implementing what I imagine is the logic behind those functions:
public static FlyoutPlacementMode GetActualFlyoutPlacement(
Rect placementTarget,
Size flyoutSize,
FlyoutPlacementMode preferredPlacement )
{
Rect ViewArea = Window.Current.Bounds;
ViewArea.X = 0; // may have non-zero offset for multi-monitor setups
ViewArea.Y = 0; // but we are only interested in offset relative to app view area
switch (preferredPlacement)
{
case FlyoutPlacementMode.Right:
if (desiredSize.Width < ViewArea.Width - placementTarget.Right) return FlyoutPlacementMode.Right;
if (desiredSize.Width < placementTarget.Left) return FlyoutPlacementMode.Left;
if (desiredSize.Height < placementTarget.Top) return FlyoutPlacementMode.Top;
return FlyoutPlacementMode.Bottom;
case FlyoutPlacementMode.Left:
...
}
}
Checkout the approach I suggested here. I believe it is better, because instead of guessing the internal placement algorithm it just compares the absolute coordinates of the flyout and the target element.