-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
B4J Question Internal Designer: How to update canvas position?
- Thread starter positrom2
- Start date
- Similar Threads Similar Threads
Thank you,
but the problem is that changes in canvas position in the Internal Designer are not reflected in the App's Java window.
For instance, the line
draws at constant position independently of the cvs1 position in the internal designer (despite that the changes are indeed shown in the WYSIWYG window).
but the problem is that changes in canvas position in the Internal Designer are not reflected in the App's Java window.
For instance, the line
B4X:
cvs1.DrawLine(0,100,cvs1.Width,100, fx.Colors.red,3)
Upvote
0
By the "Apps Java window" (should read "App's") I refererred to that window that is opened on the PC screen when the .jar file starts running, triggered by the B4J IDE "Run" button.
That window shows the data drawn in a canvas (cvs1). I was assuming when I change the canvas position (cvs1) within the designer and press "save" that this will be reflected in the appearance (position, e.g.) of the data drawn on the screen window -but it does not.
Notably, changes applied to labels are reflected correctly, so there is no question that the right form file is loaded by the B4J code.
That window shows the data drawn in a canvas (cvs1). I was assuming when I change the canvas position (cvs1) within the designer and press "save" that this will be reflected in the appearance (position, e.g.) of the data drawn on the screen window -but it does not.
Notably, changes applied to labels are reflected correctly, so there is no question that the right form file is loaded by the B4J code.
Upvote
0
Here it is. It does not show any drawn lines unless you feed it with an incoming data stream.
However, in the designer, the canvases are now arbitrarily in the lower (grey) area of the "Form" (don't know how that is called) whereas the plots are drawn just beneath the labels independently where I move the canvas position.
However, in the designer, the canvases are now arbitrarily in the lower (grey) area of the "Form" (don't know how that is called) whereas the plots are drawn just beneath the labels independently where I move the canvas position.
Upvote
0
Have you been editing the position of controls in the wrong variant ?
You have 3 variants in your design 600 x 600 , 1000 x 1000 and 1000 x 600.
Your app defines the screen as 1000 x 600
If you edit the positions of the canvas in the 1000 x 600 variant they move where you want them.
If you don't need them delete the other variants from the designer.
You have 3 variants in your design 600 x 600 , 1000 x 1000 and 1000 x 600.
Your app defines the screen as 1000 x 600
If you edit the positions of the canvas in the 1000 x 600 variant they move where you want them.
If you don't need them delete the other variants from the designer.
Upvote
0
Thanks, Daestrum.
Very strange. This is "definitely, presumably" a bug, at least an inconsistency, please correct me if not.
In the test.zip file the screen is defined as 1000x600 but that was not included in the list of variants. Any setting in the designer (match chosen variant, match the connected device etc.) does not forward changes in the canvas position to the App's screen.
Notably edits to the text fields are reflected after saving.
After changing the screen definition (that on top of the App) to one of the existing variants shown in the designer any canvas change is reflected, regardless of the chosen variant.
After that operation (once having a match between the screen definition of the App and the variants list of the designer) I can change the screen definition in the App to any value not already included in the variants list and everything still works fine -there is even no need to save the designer form, just recompiling the App is sufficient to see the changes of the canvas position.
I retested this twice by unzipping the test.zip file subsequently and I got the behaviour described above.
Very strange. This is "definitely, presumably" a bug, at least an inconsistency, please correct me if not.
In the test.zip file the screen is defined as 1000x600 but that was not included in the list of variants. Any setting in the designer (match chosen variant, match the connected device etc.) does not forward changes in the canvas position to the App's screen.
Notably edits to the text fields are reflected after saving.
After changing the screen definition (that on top of the App) to one of the existing variants shown in the designer any canvas change is reflected, regardless of the chosen variant.
After that operation (once having a match between the screen definition of the App and the variants list of the designer) I can change the screen definition in the App to any value not already included in the variants list and everything still works fine -there is even no need to save the designer form, just recompiling the App is sufficient to see the changes of the canvas position.
I retested this twice by unzipping the test.zip file subsequently and I got the behaviour described above.
Upvote
0
I don't see any bug here. You can set the abstract window size to whichever value you like. It doesn't change the variants.
You shouldn't use three variants here. It is much easier to create a single variant and use anchors + designer script to manage the UI.
You shouldn't use three variants here. It is much easier to create a single variant and use anchors + designer script to manage the UI.
Upvote
0
In short:
Unpacking a zip-saved the project with screen size defintion that is not matched by any variant of the designer does not react on changes of a canvas position wheras changes in label attributes do react (after saving the form).
Once there was a match between screen definition and one of the variants, changed canvas positions are immediately updated after re-Running the project. And this persists from thereon. I don't know what the virgin files (after unzipping) are missing -tested it twice.
And, "match the connected device" does not have the same effect (i.e., it does nothing visible).
Thanks to the hint to using anchors and script. Have to learn about that.
Unpacking a zip-saved the project with screen size defintion that is not matched by any variant of the designer does not react on changes of a canvas position wheras changes in label attributes do react (after saving the form).
Once there was a match between screen definition and one of the variants, changed canvas positions are immediately updated after re-Running the project. And this persists from thereon. I don't know what the virgin files (after unzipping) are missing -tested it twice.
And, "match the connected device" does not have the same effect (i.e., it does nothing visible).
Thanks to the hint to using anchors and script. Have to learn about that.
Upvote
0
Erel, thanks.
But here, the size of the abstract window initially is important, according to my findings:
On a freshly unpacked zip project file, there once has to be a match between the chosen variant and the screen definition. After that, the quoted statement holds.
I remember this was the case in B4A (until two years ago when I lastly programmed in B4A).
But here, the size of the abstract window initially is important, according to my findings:
On a freshly unpacked zip project file, there once has to be a match between the chosen variant and the screen definition. After that, the quoted statement holds.
Upvote
0