Build 2160 is out

aware_support

Some bug fixes (list of changes in the changelog)

Also an improvement to the behaviour of the toolbar menu.

BenHayat

aware_support wrote
Some bug fixes (list of changes in the changelog)

Also an improvement to the behavior of the toolbar menu.

Thank you Support!

weblike

thank you Support for this bug fixes...

Also the improvement was very requested by my users.

weblike

Hi,

Just updated to 2160.
Noticed that if a form is opened in a new tab and the form is larger in height than the browser cannot scroll the window.

How to reproduce: "Library" sample application -> on Dashboard try to edit some record from left panel.
Tried in many bsv files (same behaviour).

Anyone has tested this?

Thank you.

aware_support

This has been fixed in the follow-up build 2161

customaware

How is that for lightning fast support!

weblike

Awesome. Thx.
Very fast indeed 🙂

pureist

Note, Support, that the bug 'weblike' reported below DOES NOT just apply to new tabs opened containing forms whose height exceeds the height of the tab.
It applies to ANY new tab opened having content (form, query, displayed VP layout) which overflows the height (and width maybe? - I didn't check width) of the tab.
Basically, scrollbars are not enabled for new tabs.
And congratulations on getting tab scrolling to work properly, where the tab itself now scrolls when its contents overflows it, rather than prior to this build where the entire frame would scroll to reveal the overflowing contents which meant the tab row itself scrolling and disappearing off screen.
.
Since you're gonna be tinkering around with tab hardcoded settings to fix this bug, perhaps you could also at the same time attend to a long outstanding new tab related bug previously reported and discussed in depth on this forum..
=>New tabs opened have excessive AND UNEVEN hard-coded margins.
.
These can now be overridden by a displayed VP layout (previous bug fix), but otherwise they still remain for new tabs whose content is a form or query.
.
It appears as though the left margin is 15, and the others are either all 10, or except the top which is 5.
As well as being uneven, they are excessive and a waste of real estate when designing a layout for a small screen.
A compromise between where they are now and zero (cause I know you don't think zero is a good idea) would be to hardcode them ALL to be 5px. Refer image inset at bottom which shows how they are now.

weblike wrote
Hi,
Just updated to 2160.
Noticed that if a form is opened in a new tab and the form is larger in height than the browser cannot scroll the window.

aware_support wrote
This has been fixed in the follow-up build 2161

aware_support

Are you saying the bug is present in build 2161 that was specifically released to address it?

pureist

Support: my post 2 posts back was in draft for hours while i did other work. by the time i finished and posted it, you had posted about 2161, though obviously I hadn't seen it due to my draft post being on screen.
And the scroll bars on new tabs are now appearing in 2161!
The only bug which remains is the uneven and excessive hardcoded default margins which are still applied to new tabs which contain a form or a query (ie. not content sourced other than via DISPLAY LAYOUT), which is clearly illustrated in the image in my post 2 posts back.

aware_support wrote
Are you saying the bug is present in build 2161 that was specifically released to address it?

pureist

having now thoroughly checked, contrary to what I wrote in the previous post, there ARE still bugs in b2161:

1a. in your testing bsv, add a button to make make a new tab open containing a query WITH a fixed height exceeding the height of the tab
1b. scroll down on the new tab and you will notice that the bottom of the query or its paging bar (if it has one) is cropped off by about half the height of 1 row

2a. in your testing bsv, add a new button to make a new tab open containing a query WITHOUT a fixed height
2b. make sure the query has a panel toolBAR (I tested with it at the top)
2c. click the button 6 times (to open 6 tabs containing that query)
2d. examine the content of all 6 tabs
2e. you will notice that even though the query does not have a fixed height, it has been expanded somehow to exceed the height of the tab
2f. AND you will notice that the height of the query is different on many tabs and on at least one of the tabs the query height fits exactly the height of the tab

pureist

and append to the previous post:
.

horizontal scroll bars do not appear under any circumstances either on new tabs OR pre-defined tabs, irrespective of their content, or source thereof

aware_support

Could you please send the BSV where we could easily reproduce the problems?

pureist

Don't you have a bsv you can quickly edit in under 10 seconds to change the width of a content panel of a predefined tab to be 4000, and width AND height of a query which opens in a new tab to be 4000, and then run it and see that horizontal scroll bars don't appear under any circumstances and the bottom of the query is cropped, as described in detail in my previous post?
How can i post it here? it only lets me attach jpg files, even if they are a bsv with a jpg extension?
It is quicker and easier to attach them to a post here than setting up dedicated emails all the time.

aware_support wrote
Could you please send the BSV where we could easily reproduce the problems?

tford

purist,

Support has a great reputation for solving bugs if you send them a zipped mini-BSV with specific instructions on how to reproduce the bug behavior in the BSV. When I send them bug reports in this manner, I include steps to reproduce labeled 1, 2, 3, etc along with appropriate screen shots. It rarely takes me more than 15-20 minutes to make the BSV & send the email.

This process makes it VERY EFFICIENT for support to find and solve the bug. When users really want a bug solved, I strongly recommend this process.

intra

Totally agree with tford!

You need to understand that under the hood there's most likely thousands of lines of code. By submitting an example it helps support isolate the issue quickly and then do some QC/QA to verify that its been fixed.

I normally send a short description of the issue, record a short mp4 video clip and submit the BSV.

Normally support confirms if it is a bug and then gives an estimated timeline on when an expected fix likely be completed.

aware_support

tford and intra are spot-on.

Not to mention that the biggest problem for us is that very often when we try to reproduce a problem from a verbal description, we often cannot reproduce it. This is because quite often it's the minor details that count and we need to do EXACTLY the same things and in EXACTLY the same environment to reproduce the problem. Therefore, we often just don't want to waste the time trying to reproduce problems from verbal description alone.

Sending us the BSV (by email to support@awareim.com, not by forum) with the exact description on how to reproduce the problem HELPS ENORMOUSLY.

I don't know how many times we have tried to explain this - see the sticky post on the Problems Reports forum, for example.

pureist

Yes Tom, I know.
BUT for something so elementary and simple as these bugs (horizontal scroll bars never appearing, and bottom of queries being cropped when vertical scroll bars are present) where Support can just change IN 30 SECONDS the width and height of components in ANY BSV already on their system and run the bsv and see the bugs for themselves, it is superfluous that I should also have to spend more time preparing and sending a bsv.

And if I'm really gonna have to, then I should be able to attach it here, as this forum is a pinned tab, thus it is the most time efficient method.

My time is valuable just like Support's is.
I already expended considerable valuable time in doing the QC work which wasn't done fully, in finding these bugs which neither Support nor any other user reported. I also identified that the vertical scroll bar was not appearing in all scenarios, not just when a tab's content is a form, which is something which was not reported when it was first reported that "..[if] form is larger in height than the browser cannot scroll the window".

And I obviously didn't just test for these specific bugs.
No, as I always do, I tested for all possible operational scenarios, configurations, permutations, (hence the instruction in my bug report post to have a toolbar on the query) and found these bugs. That time spent comprehensively testing is substantial.

It is about BALANCE.
I've spent MASSIVE amounts of time in testing, locating, and reporting bugs to assist Support so hopefully Support can assist us by getting the product to a level/state we require.
Over the last few months I have sent 39 bug report emails, containing 82 bugs.

But when a bug is something absolutely trivial and very quickly and easily reproducable, it is inequitable (considering the time I already expended in qualifying the bugs) that I should also need to then spend even more time creating a bsv with sample data, exporting it, logging into email, setting up an email, blah, blah, blah.

It is about balance. I send emails when, on balance (based on the nature and complexity of the bug), I think it is appropriate, which is almost all of the time.

Have a look at the attached. Obviously I'm not gonna report those bugs here. I'm going to send a detailed email when I have time. But I prepared that jpg over a month ago and still haven't reported them via email because of time constraints.

tford wrote
purist,
Support has a great reputation for solving bugs if you send them a zipped mini-BSV with specific instructions on how to reproduce the bug behavior in the BSV. When I send them bug reports in this manner, I include steps to reproduce labeled 1, 2, 3, etc along with appropriate screen shots. It rarely takes me more than 15-20 minutes to make the BSV & send the email.
This process makes it VERY EFFICIENT for support to find and solve the bug. When users really want a bug solved, I strongly recommend this process.

rob_h7

You could have built 2 bsvs and sent them in in the time it took you to write that post.

pureist

yes, but that is not the point. the point is, all the cumulative time going forward superfluously preparing bsv's for trivial bugs.
and in the time it took you to write and post your reply below, you could have created a new bsv, changed the dimensions of the content panel in the tab of the main frame to be 10000x4000, run it, and seen a bug I reported.

rob_h7 wrote
You could have built 2 bsvs and sent them in in the time it took you to write that post.