MegaHurts Wish List for Visual-TFT

[Megahurts]

Hi ME Team,

I would like to suggest there to be an additional component added for labels:

This label object should have the following properties removed from its structure that are not required for its implementation.
Current 'Static' labels are structured like this;

Code: Select all

structure TCLabel
  dim OwnerScreenID        as word
  dim Order                as byte
  dim Left_                as word
  dim Top                  as word
  dim Width                as word
  dim Height               as word
  dim Caption              as ^ const char
  dim Fontname             as ^ const byte
  dim Font_Color           as word
  dim Visible              as byte
  dim Active               as byte
  dim OnUpPtr              as ^TOnEventPtr
  dim OnDownPtr            as ^TOnEventPtr
  dim OnClickPtr           as ^TOnEventPtr
  dim OnPressPtr           as ^TOnEventPtr
end structure code

I think there is a need for a simpler one that saves memory and less parameters to configure for usages where we do not need
these property options for labels that never change, never need event actions or be anything but static 'dead' characters on the screen.

So here is my proposed new object structure:

Code: Select all

structure TCLabel
  dim OwnerScreenID        as word
  dim Order                as byte
  dim Left_                as word
  dim Top                  as word
  dim Width                as word
  dim Height               as word
  dim Caption              as ^ const char
  dim Fontname             as ^ const byte
  dim Font_Color           as word
  dim Visible              as byte  ' ? is changeable in a "static" object ???
end structure code

Having the "Visible" property could still be useful, IF it would have an effect, but a true "static" object by V-TFT definition has no
changeable properties (stored entirely in ROM?).
If not state changeable from code, Visible property should also be removed and the non-static label used instead when users need
labels that are dynamic intended.

Changes to label draw routine(s) are required to accommodate or entirely different routine be used.

A non-static version with "Visible" property would satisfy needs for having a label toggle on/off displayed, but all other properties
not required to save memory usage.

How much object memory would be saved/recovered with this proposal? Enough to justify adding?

Thanks, Robert.

[Megahurts]

Hi ME Team,
Congrats on CEO Award. Well earned.

Thanks for the Hard work done on V-TFT too.

But they are never done either, right?

Please consider these functions for future additions:

1 - Add value increase/decrease buttons to all object property numerical value fields, (always visible please.)?
(Would allow moving/sizing an Object only on one field value at a time quickly and accurately.)

2 - Add right-click object menu items "Move Up a Layer" and "Move Down a Layer" (screen X,Y location remains same).
Then add/change right-clicking a location on screen area to "Paste" a Cut/Copied object will put it at that location.
(Center object on mouse pointers point or object Top-Left Corner at that point)

Thanks and Congratulations again, Robert.

[Megahurts]

Hi ME Team,

A possible handy function for working with layers:
If there was another switch on the layers control window to allow "Locking to a Layer",
There would be no chance of accidentally placing an object on the wrong layer.
(This happens to me a lot even when I set layers to states that should not allow it to happen)

Of course, fixing the way layers work now so that it works the way intended would fix this issue too...

But having this function too would be nice also.

Robert.

[filip]

Hi,

There is a Lock Layer icon in the Layers Window that does this, lock the layer and the Visual TFT will pop-up an error saying that you cannot add any component to a layer if you don't unlock it.

Regards,
Filip.

[JohnGB]

I don't think that is what Megahurts was saying.
I think what was asked for is a function that would by default edit or add controls on a specific layer.

[Megahurts]

I don't think that is what Megahurts was saying.
I think what was asked for is a function that would by default edit or add controls on a specific layer.

Yes, Thank you JohnGB.

Filip, please reread what I had posted, V-TFT has a bug that does not ensure objects get placed where a user tried to place it (on which layer).

When I am working on a layer, and only wanting to add or edit objects to that layer, V-TFT will at some point, ALWAYS switch
layers on me when I did not want it to.

You have to actually use the software and try to build something complex to see the problems we are getting I think.

Robert.

[Megahurts]

Good Morning MikroE,

Quick Question if a possible V-TFT Layers control switches arraignment might be considered?

Would adding another control to each Layer called "Object Lock" that does what "Layer Lock" does now (locks all editing of Objects on that Layer),
and changing "Layer Lock"'s function to locking all object editing activity to only that layer set to lock and not object locked)?
(Only one layer can be locked to at at time and must be unlocked so selecting other Objects/Layers groupings is possible)?

I do not know if the "Visual" state of objects on the screen editing area is only way programmable for V-TFT to ignore making selections of objects
the mouse pointer (maybe?) interacts with. ??

Or if implementation would make problems in programming with the many object operations in V-TFT reason(s) it can not be done?

Many Thanks again, Robert.

[Megahurts]

Hi MikroE Team,

I have a few questions and a suggestion about RadioButton components:

Due to other V-TFT bug issues I have not been able to test this out on any hardware.

I am wondering why there was not an inclusion in the RadioButton component properties that allowed grouping 2 or more of them to
a logical option selection group?

Due to lack of any substantial documentation for this component, I (we) have to assume that all operations of changing and keeping track
of which radio button is selected is to be done by the user?

Can there even be more than one group of radio buttons per screen? This image below shows why I am concerned about this:

radiobutton_grouping.jpg (23.61 KiB) Viewed 8802 times

This code listing is from my project and in the driver file. It shows that V-TFT has grouped ALL radio buttons on this screen to one declaration.
Does this mean ONLY one of them can be selected at a time?
I have 2 groups of 3 each placed on the screen in V-TFT, but now unsure if there can even be more than 1 logical group usage of them.

If the user is totally responsible for coding each groups function, OK, I can do that, but worried I might be wasting time trying if
the radio buttons are limited to only 1 option selection group on a screen.

Answers to those questions would be greatly useful.

Now for a proposal:
Add properties to the RadioButton component that allows associating the buttons to a logical selection group and coding the handling routines
so that the user does not have to create the coding to do the changing of which is selected, they just have to make code that
looks at a property byte value that the V-TFT radio button code updates to which one is selected in that group.

The logical grouping property should only need to be of byte size to allow for 256 possible groupings in a V-TFT project.
This would allow more than 1 group per screen if the above questioned limit exists.

I do not know if Delphi does this, but VisualBasic for windows made you group Radio Buttons into groups so only 1 in a group is ever selected.
I do not understand fully why you did not 'complete' the implementation for radio buttons like this in V-TFT.

I can see that having the user do all of that coding and not having V-TFT routines generated to do it leaves the buttons open to
users making the radio buttons do other tasks than just being radio buttons. I am trying to do so myself in a project.
So in order to preserve this powerful option for open programming of the buttons, I suggest that if you do change to a grouping property,
that a zero (0) value for any radio buttons group property means those buttons are not part of any group (open usage).
Values 1-255 are used to group the buttons into logical selection groups. This should be more than enough for any application.

(I would do the programming to change them to operate like this in V-TFT generated code if V-TFT allowed it. But we can not at present, so must ask you for the changes. )

Thanks, Robert.

[FrancisV]

i have an actual project with about 60 screens.
VTFT is strugling for about 50 seconds to load the program from disk...
As this program together with code only takes 36% of the resources of PIC32 i'm wondering if VTFT is able to handle bigger programs ?
(i'm still extending my program ...)

Best Regards,
Francis

[Megahurts]

Hi all,

i have an actual project with about 60 screens.
VTFT is strugling for about 50 seconds to load the program from disk...
As this program together with code only takes 36% of the resources of PIC32 i'm wondering if VTFT is able to handle bigger programs ?
(i'm still extending my program ...)

Wow, that's a lot of screens Francis. I guess you will be the one who finds out if there is a limit to a V-TFT projects size. lol

If your projects are anything like mine are, you must be going nuts trying to keep track of everything. Good luck.

thanks everyone for the input and I hope we see some good changes in V-TFT soon, Robert.

[Megahurts]

Hello mikroe Team,

It has been awhile since last request so it is time for one more since new version is not out yet.
Hopefully it can make it in before next release, because it should be a simple one to implement, I think?

Can you guys change V-TFT so that there is a underscore before the action event suffix added to object names used in naming
the routines please?

Example:
Currently we get this for a routine name for a Button clicked event assignment generated by V-TFT:

Code: Select all

sub procedure ButtonRound1OnClick()

end sub

sub procedure ButtonRound2OnClick()

end sub

sub procedure ButtonRound3OnClick()

end sub

I think and know it much easier to read if it is like this (I know, because I rename my objects before assigning events now):

Code: Select all

sub procedure ButtonRound1_OnClick()

end sub

sub procedure ButtonRound2_OnClick()

end sub

sub procedure ButtonRound3_OnClick()

end sub

Finding the right routine name amidst a lot of routines that have the same ending characters without separation from the characters that are different in each objects name is hard the way it is now.
This is why I have begun renaming every touch object before assigning events, but it would be better if V-TFT did it instead.
My objects names are now a little cryptic like this: ButtonRound1_
for using in my coding and if forget to add underscore while typing names, causes naming errors in compiler.

Please consider making V-TFT add the _underscore before the events suffix appending to objects name so we can use regular
names and have readable code.

Thank you for the consideration, Robert.

[Megahurts]

Hi Gentlemen (and any Ladies),

I want to propose that there be a window of some sort (pop-up, dock-able?), be added to the FT800 Eve tools that shows the User
a list of 'Tag' numbers (1-254), the user has used so far assigning to touch objects. (values 0 and 255 excluded of course.)

Too time consuming to hunt for used or unused Tag numbers by clicking on each object. Plus trying to rapidly click on different objects
to inspect its properties can easily cause a movement of the objects placement if mouse pointer is not absolutely stationary when left button is clicked.

If there is a way to stop this inadvertent moving of an object when trying to select one, it would reduce users time spent fixing them,
IF they realize it happened when it does.

At first, missing the occurrences of it happening is easy, after dealing with objects misalignment's many times, you start checking for this
every time selecting a object.
I find this repetitive action taxing mentally and physically and a distraction from mentally organizing a projects requirements to be done.

Can you add to V-TFT a few microseconds of delay after clicking on an object(s) before any placement (movement), dragging can be allowed?

This would sure help my editing sessions go faster, better and with less re-adjusting of the parts.

Again, thanks for taking notice and the work being done to improve the products, Robert.

[OT]

Yes this accidental moving of objects is disconcerting. It does not make it easier and more comforting that even if the mouse does not move (keeping it absolutely still by holding it down) some objects, e.g. radiobuttons, appear to move back and forth when selected. So it is very hard to see if the position was permanently changed.

One solution to this is locking a layer to prevent objects from moving when inspecting them. However my wish would be that components still could be selected (as one can do now) and properties edited in the component editor (as one cannot do now) even when a layer is locked. This would make the process of assigning proper names and events to components much easier and secure. As it is now, if one tries to edit properties of a component in a locked layer, no warning is given that the edit did not go through, it appears to take it but it is gone when the component is opened the next time. I think it would be better to let the edit of the property be done.

A keyboard shortcut for toggling the lock would be very useful. Also the visibility of the lock symbol needs to made better. It is hardly visible against the gray background when a layer is selected.

While at it, the layer's logic need some work. I was able to paste a component into layer0 from layer1 even when layer0 was locked. I intended to copy it into layer1, and layer1 was marked as the active layer. I think when having a component marked in one layer and doing and Edit-Copy, and then switching focus to another layer and doing a Copy-Paste the copied component should end up in the layer that is marked provided that it is not locked. [Edit: and I now see that that is how the help system indicates that it should be working].

I should add that only components in the selected layer should be selectable...

[Megahurts]

Hi All,

Thanks OT for clarifying the issue I was trying to describe, good job at it. Here is a work around I have come across for this also:

I have noticed that when using the selection modifier keyboard key "SHIFT", that the objects do not "jump" when being selected.
(used to make/unmake multiple object selections)

But even if you need to select an object to examine or change a property, if you first click outside of the screen editing area, so nothing is selected,
then hold down the "SHIFT" key and make your object selection, it will not jump or move even if the mouse pointer is moving slightly.


It would be a great improvement to V-TFT if all object selections on the screen editing area behaved this way though, Robert.

[OT]

Thanks Robert, that is a very useful tip!