Odd positioning of embedded Web Containers at runtime

Hi folks,

I’m really struggling with the positioning of embedded containers within Web Containers. When I add a container vertically at runtime, the “top” positioning bears no relation to the top value I’m setting. I’ve specified a “top” to which I add the height of the container for stacking vertically in a loop (plus a small spacer). The output bears no relation to the specified position, creating a huge gap between the controls. I’ve used the Style.Value(“top”) method and this positions things as expected, but this creates all sorts of very strange side-effects. Here’s my code.

Var top As integer =2 'First row should, theoretically be near the top?!
Var pRow As DataBar 'My container… Height = 46

For pCount As Integer = 0 to mRows
pRow = new DataBar
pRow.Embedwithin(Me, 6, top, pRow.Width, pRow.Height)
top = top + (pRow.Height + 2)
Records.Add(pRow)
Next

My other problem is the speed. We do assessments in excel, and I’m trying to replicate our assessment framework in Xojo. We have 120+ lines in each assessment. Just adding the equivalent of one cell per row takes 19 seconds! I will be needing 9 columns, so this will require a lunch break while loading. I can’t help but think that I’m doing something fundamentally wrong? Any help please?

image

Here’s the output…

Hi Simon,

I have exactly the same 2 problems in my Webapp. Unfortunately I have no solution. I think that the containers in Web Framework 2.0 are not yet fully developed. Hope that brings improvement in the next release.

Hi Wolfgang,

It’s very frustrating. I really love the product (the concepts and the language) and I really want to use it, but it feels unfinished and the results are slow and too often unpredictable. As a bluff old traditionalist, when I specify the position of a control, I expect it to appear there - and quickly.

It sounds like you’re having similar problems. I guess we’ll just have to wait for Web Framework 2.0 to become stable and usable. I’ve been wondering who Xojo’s target users are. If you don’t mind me asking, why did you choose Xojo?

My impression is that the obvious market for Xojo is MS Office users. They’ve long been cut adrift by Microsoft in their sprint to .NET and Java. Xojo would be instantly familiar to literally millions of business-orientated, technically competent Excel and Access users who currently write code in VBA. It would only take a single, configurable grid control (mimicking an Excel “sheet” / Access “sub-form”) for every competent Office pilot to start moving their Office-bound tools to the web.

When I was looking to move an Excel app to the web, Xojo seemed to be hidden away and marketed as a “cross platform development” tool. Surely their huge USP is the familiarity and accessibility of the language to millions of Office users? I thought the folks at Xojo would scream “VBA for the web” and grab a slice of the market that has created 30+ million VBA macro-enabled documents and has nowhere to go. A “best kept secret” marketing strategy, I guess.

Just for its familiarity and conceptual elegance, I’m going to persevere with it.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.