*{Visual-TFT Users}
How are you all doing this fine day? Good I hope, and wishing you all have a great weekend holiday and come back safely.
I'll be taking a trip next weekend to a family reunion event, so today is a good day to share something with you all.
Sorry, but it is only a Puzzle/Problem, and one that if solved, has great potential for making our projects Rock and Roll.
This may not be what you might expect sorry, but I hope you all find it interesting and hopefully inspiration will strike you like a lightning bolt,
but without the smoke and sparks and smell, OK? ;^)
(Never good getting any of those indicators)
The puzzle/problem is with those darn variable pointers and proper usage.
In this case, the proper usage is dictated by utilizing a scheme that a user can easily implement with V-TFT objects properties and
not break or corrupt the data structure that is being used by the V-TFT object drawing/handling routines.
(not so easy to do, I've tried and had no luck so far, but I don't possess the knowledge and experience with pointers some of you have.)
I am trying to set up some pointers for some V-TFT objects properties and having no luck getting it to work correctly yet or not cause compiler build errors.
The concept is to change a few object properties/structures data holders so they can be set as a group to use the same
data of a single variable, instead of each property in the objects data structure having its own variable to hold a property's setting.
If this is possible, we can have many objects AND many of their properties tied together as a group and all be subject
to the data value of a single variable. This will reduce code size a lot and provide easier, simpler control over many objects
that we can not do at present. (much of the code that would be reduced/eliminated will be the user code needed to assign different
data values to the properties on a one by one basis as is done now, see the example code of this below that shows potential diferences.)
I hope someone can 'point' me (/Us) in the right direction please?
Results wanted (trying to do) for this pointer usage:
I have on the bottom of a TFT screen a set of 5 menu buttons (spaced side by side along bottom edge), that can be replaced by another one of
3 other sets* of buttons of same size and position for 4 sets* total. *(also called a 'group' : of some same characteristic(s) or traits)
Another screen button cycles the sets when pressed. See image below for example of menu sets displayed and button to cycle them.(highlighted with red boxes)
- cnc stepper menus.jpg (222.68 KiB) Viewed 11845 times
'Visibility', 'Active' and 'Press Color Enabled' properties set to 'True'(1), the other 3 Menu sets
same properties are set to 'False'(0), so not visible and won't react to a press on the screen at their locations.
When the button that cycles the menu sets is pressed (clicked), its event handler routine updates a tracking variables
value for which set is active (0,1,2,3).
Then that tracking variable is subjected to a 'select case' operation to use which case = True(1) code that will change 4 different flag variables data values so new active set flag = True (1) and the last menu sets flag variable = False (0).
These flag variables declarations are User Code and I placed them in the Udriver module - near top of file: (one for each button set)
Code: Select all
' User Code Object Group Control Flag Variables.
dim MENU1_ENABLED as ^byte ' pointee variable to have group-1 objects controlled properties use
MENU2_ENABLED as ^byte ' pointee variable to have group-2 objects controlled properties use
MENU3_ENABLED as ^byte ' pointee variable to have group-3 objects controlled properties use
MENU4_ENABLED as ^byte ' pointee variable to have group-4 objects controlled properties useThe now active set of buttons are then redrawn over the last set and ready to be pressed for their function/action the user programmed for them.
(I do not know if or think the right declaration(s) practice is being done to establish a "Pointee"* for the pointers,
or if a new type definition of a pointer for these variables is required in order for the objects properties/parameters to still
be accepted/usable by the V-TFT core code?) *{Pointee – the variable or memory location a pointer points to.}
The affected 'Elements' to correctly modify/manage by doing this (? I'm not sure if all or some or missing are right/needed/listed):
For an example to help show what I am trying to do, I'll list just the minimum amount of code from the project for the objects necessary.
First though, I am making these changes to the code V-TFT generates in a projects 'driver' and 'objects' files that are copies of the originals
and renamed (ie..~xxx_driver.xxxx -> ~xxx_Udriver.xxxx), and originals have all code commented out (for testing before removing from the projects files list).
The remaining V-TFT project files have their 'Includes' edited to use the copied files I am modifying.
(this is also a test of best way to enhance users control of V-TFT objects and preserve the user edited V-TFT code it will overwrite if edited in V-TFT again)
The Menu Buttons used in the sets are dynamic-memory-allocated same type square Buttons.
Here is code listing of the Button objects structure declarations from the projects 'Uobjects' file/module.
There has been 5 common property elements data types changed by me to a pointer type of original data type.
They are shown marked with a comment at right of structure element/member declaration.
3 members (object properties) are used in a group of same function of flag logic needs to be used/set identical by all menu buttons in a group:
Visibility, Active and ColorOnPress_enabled - are all set 0 or 1 at all times for the usage
characteristic I intend to use here. (these 3 properties are the necessary ones to control an object being visible and active to TP activity over them)
Other 2 members, Transparency and Gradient_Enabled are used by only some of the buttons in the menu sets.
Code: Select all
structure TButton
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 Pen_Width as byte
dim Pen_Color as word
dim Visible as ^byte ' modified by me: added pointer carat to type declared (Used by button set management code)
dim Active as ^byte ' modified by me: added pointer carat to type declared (Used by button set management code)
dim Transparent as ^byte ' modified by me: added pointer carat to type declared (not used by button set management code)
dim Caption as ^char
dim TextAlign as byte
dim Fontname as ^ const far byte
dim Font_Color as word
dim Gradient as ^byte ' modified by me: added pointer carat to type declared (not used by button set management code)
dim Gradient_Orientation as byte
dim Gradient_Start_Color as word
dim Gradient_End_Color as word
dim Color as word
dim PressColEnabled as ^byte ' modified by me: added pointer carat to type declared (Used by button set management code)
dim Press_Color as word
dim OnUpPtr as ^TOnEventPtr
dim OnDownPtr as ^TOnEventPtr
dim OnClickPtr as ^TOnEventPtr
dim OnPressPtr as ^TOnEventPtr
end structurethe grouped set be Disabled (not visible, no TP events triggered) or Enabled (visible,active to touch) correctly,
then current active/Enabled set redrawn on screen.
(I'm pretty sure that the modifications to data members is not the right way it needs to be done....HELP!)
The object elements (properties) unused by menu mgr. function are to be individually manipulated by each buttons event handler routine, if those properties are used at all.
Only a few buttons in menu sets will use those properties for changing button appearance to indicate assigned functions current state.
The problem(s) I have with this part of trying to set this up:
1. This modification of an elements type declaration here will now be applied to ALL Button Objects used in the project.
I'm not sure we would want that and doing what I did has caused conflict in the V-TFT core driver code for those objects.
(I am not sure what I changed is actual problem, but how the code syntax/pointer-usage in other modules is done or the wrong pointer method/way for this data sharing structure modification or the (full) pointer implementation structure not fully established yet ?)2971 373 Pointers can be compared to compatible pointers or zero value PIC33EP_CNC_Stepper_Udriver.mbas
Looking for the best/simpler/better implementation solution possible.
So, to control all wanted properties by having those properties 'grouped' (for controlling multiple object properties with 1 variable, instead of setting multiple values one by one) together in each object to use same value in another variable (or memory location) and all 5 buttons of a set (grouped again by set, so = 15 properties {3x5} pointing to same 'pointee') all use that same 'pointee' value, and each set has its own 'pointee' that controls all buttons in the set,
Is this change to the objects type structure required?
2. I think this now requires modifying the objects elements assignment code in "InitializeObjects()" routine in 'driver' module also (or not?), but I don't know if every object of same button type used in project now also requires changes to its affected property elements in the initialization routine and every instance that a modified properties
data element is to be assigned a data value.
3. I really need a proper example (please) of how to point a few of an objects property structured data members to the same defined data value holder, and example of setting up that value holder (properly as a 'pointee') and accessing it for read/write (directly(?) by user code to modify value, and object(s) properties seeing value properly with V-TFT core driver code being able to use the value assigned (where stored?).
Here is example of a menu button entry and assignments from the "InitializeObjects()" routine in modified "Udriver" module:
Code: Select all
Scrn1Btn_Menu1_DRILL_.OwnerScreenID = 32768
Scrn1Btn_Menu1_DRILL_.Order = 1
Scrn1Btn_Menu1_DRILL_.Left_ = 214
Scrn1Btn_Menu1_DRILL_.Top = 222
Scrn1Btn_Menu1_DRILL_.Width = 51
Scrn1Btn_Menu1_DRILL_.Height = 17
Scrn1Btn_Menu1_DRILL_.Pen_Width = 1
Scrn1Btn_Menu1_DRILL_.Pen_Color = 0xFFFF
Scrn1Btn_Menu1_DRILL_^.Visible = MENU1_ENABLED ' modified by me: added pointer carat to type declared (used by button set management code)
Scrn1Btn_Menu1_DRILL_^.Active = MENU1_ENABLED ' modified by me: added pointer carat to type declared (used by button set management code)
Scrn1Btn_Menu1_DRILL_^.Transparent = 1 ' modified by me: added pointer carat to type declared (not used by button set management code or know if needed to be done in any case?)
Scrn1Btn_Menu1_DRILL_.Caption = @Scrn1Btn_Menu1_DRILL__Caption
Scrn1Btn_Menu1_DRILL__Caption = "DRILL"
Scrn1Btn_Menu1_DRILL_.TextAlign = _taCenter
Scrn1Btn_Menu1_DRILL_.FontName = @Tahoma13x13_Bold
Scrn1Btn_Menu1_DRILL_^.PressColEnabled = MENU1_ENABLED ' modified by me: added pointer carat to type declared (used by button set management code)
Scrn1Btn_Menu1_DRILL_.Font_Color = 0xFFFF
Scrn1Btn_Menu1_DRILL_^.Gradient = 1 ' modified by me: added pointer carat to type declared (used by buttons event handler code)
Scrn1Btn_Menu1_DRILL_.Gradient_Orientation = 0
Scrn1Btn_Menu1_DRILL_.Gradient_Start_Color = 0x8410
Scrn1Btn_Menu1_DRILL_.Gradient_End_Color = 0x39E7
Scrn1Btn_Menu1_DRILL_.Color = 0xF800
Scrn1Btn_Menu1_DRILL_.Press_Color = 0xC618
Scrn1Btn_Menu1_DRILL_.OnUpPtr = 0
Scrn1Btn_Menu1_DRILL_.OnDownPtr = 0
Scrn1Btn_Menu1_DRILL_.OnClickPtr = @Scrn1Btn_Menu1_DRILL_OnClick
Scrn1Btn_Menu1_DRILL_.OnPressPtr = 0With my rudimentary skills on pointers and no examples in compiler documentation on using pointers in structures like the ones
V-TFT objects are made as, I am unable to get a working configuration solution.
I think this is a possible method to implement and it can reduce the size of users code required to manipulate multiple objects
properties by a large factor (the more objects in a group, the more code space saved by # of properties in a object grouped x # of objects in a group together).
The way I am trying to do this can also be applied to objects that a user has set up to be pop-up input dialogs or messages
that are to be used on a single screen (pop-up windows on a screen would now be very easy to implement),
making the control and management of them much easier and efficient with smaller code footprint needed.
aCkO has already shown us (in his tutorial for reusing objects on different screens), that the current screen-object structure uses
more memory than required because of the structures V-TFT is programmed to create and I have hopes this method can save us even more if put to use. (imagine if both of these were to be implemented in V-TFT
)The current method of coding requirements to change the set of menu buttons in my project is shown in this code listing below. I will show one (1) Menu sets minimum required properties changing code entries for an object of that set and one objects properties
of the last Menu group, so multiply these code lines by the number of buttons and Menu sets to get idea of the amount of
code needed to implement this simple set swapping technique as we have to do it now.
Code: Select all
'---------- Start of Screen1 Menu Navigation Button handling
sub procedure Scrn1Btn_MenuCHANGE_OnClick()
' changes Active, Visible, Press color properties of 4 menu button sets (5 buttons each)
if (MENU_PAGE = 3) then ' cycle to next menu or roll over to first menu
MENU_PAGE = 0
else
inc(MENU_PAGE)
end if
select case MENU_PAGE ' change properties and redraw current active set
case 0 ' Menu 1 set active
Scrn1Btn_Menu1_DRILL_.Visible = 1 ' 3 property entries for a button to be made active
Scrn1Btn_Menu1_DRILL_.Active = 1
Scrn1Btn_Menu1_DRILL_.PressColEnabled = 1
' 4 more required for the set of buttons to make the set active
'
'
'
'
Scrn1Btn_Menu4_SETUP_.Visible = 0 ' 3 property entries for a button to be made inactive
Scrn1Btn_Menu4_SETUP_.Active = 0
Scrn1Btn_Menu4_SETUP_.PressColEnabled = 0
' and 4 more required for the set of buttons to make the set inactive
'
'
'
'
' 5 drawbutton routine calls to draw set 1 on display so they are visible now
case 1 ' Menu 2 set active
' and now repeat the same amount of code here to switch menu set 2 to active and menu set 1 to inactive
'
'
'
'
'
'
'...
case 2 ' Menu 3 set active
' and now repeat the same amount of code here to switch menu set 3 to active and menu set 2 to inactive
'
'
'
'
'
'
'...
case 3 ' Menu 4 set active
' and now repeat the same amount of code here to switch menu set 4 to active and menu set 3 to inactive
'
'
'
'
'
'
'...
end select
end sub
'---------- End of Screen1 Menu Navigation Button handlingCode: Select all
'---------- Start of Screen1 Menu Navigation Button handling
sub procedure Scrn1Btn_MenuCHANGE_OnClick()
' changes Active, Visible, Press color properties of 4 menu button sets (5 buttons each)
if (MENU_PAGE = 3) then ' cycle to next menu or roll over to first menu
MENU_PAGE = 0
else
inc(MENU_PAGE)
end if
select case MENU_PAGE ' change properties and redraw current active set
case 0 ' Menu 1 set active
MENU1_ENABLED^ = 1 ' enables all 5 buttons in the set
MENU4_ENABLED^ = 0 ' disables all 5 buttons in the set
' 5 drawbutton routine calls to draw Menu set 1 buttons on display so they are visible and usable now
case 1 ' Menu 2 set active
MENU2_ENABLED^ = 1
MENU1_ENABLED^ = 0
' 5 drawbutton routine calls to draw Menu set 2 buttons on display so they are visible and usable now
case 2 ' Menu 3 set active
MENU3_ENABLED^ = 1
MENU2_ENABLED^ = 0
' 5 drawbutton routine calls to draw Menu set 3 buttons on display so they are visible and usable now
case 3 ' Menu 4 set active
MENU4_ENABLED^ = 1
MENU3_ENABLED^ = 0
' 5 drawbutton routine calls to draw Menu set 4 buttons on display so they are visible and usable now
end select
end sub
'---------- End of Screen1 Menu Navigation Button handlingThe program execution time for this routine will be significantly lower also, and that is usually a very good thing too.
So, YES, this is also a V-TFT Wish list change request: Add controls to V-TFT to allow users to group an objects selected properties
*(of same data type value controlled) together (point to a single variable) and group selected objects so the output code has “User Code” control over the pointers structure and referencing allowing changes to suit users needs/design requirements.
(I may not have phrased that (or anything about pointers in the posting) correctly in regards to correct pointer terminology
sorry, as I have stated – NOT an expert or skilled with their usage at all, if any of the above did not make any sense to
anyone, please ask and I will try to provide better explanation(s) to clarify it.)
If what I do understand about pointer-usages is correct, this is entirely possible within the compilers, but I make no claims
that it can be done with current V-TFT object data structures and related object handling code as it exists now.
An expert in this area needs to consider and explore this concept, and hopefully provide an affirmative reply (or let it be known
that it can not be done with these data structures, currently?).
My fear for this idea to easily be implemented currently by users editing an objects properties structure(s), is that the current
object data structure after modification will not allow the object(s) to be processed correctly or at all by the current V-TFT
core routines, without doing modifications to every V-TFT routines code entry for that object types properties affected.
The one thing I do not want done is to create a system that requires even more code to implement the feature, or require the user to edit hundreds of routine entries that use the modified structures data element(s).
But I do think that if V-TFT were to be changed so users could optionally tie any of an objects same-type properties to a single state holder variable and set up multiple instances of properties that are tied to a single holder variable (different variable for each set of tied properties, user supplies the identifier name, V-TFT puts it properly declared in generated code)
and be able to assign this configuration to as many objects (with the same properties shared) as user desires,
it would be a very powerful and versatile upgrade to the things possible with using V-TFT.
Many, many things could be made possible for users to take advantage of if this were implemented in V-TFT.
I'm sure there are more than I have thought of so far, but at a minimum, what it can provide to us users is greatly desirable for better, easier control of many objects and with reduced code footprint needed.
I may not be online until next week sometime, so please consider this concept and post any questions, suggestions or remarks or usable solution code examples you have so we can expand the capabilities possible with our treasures of HW and SW tools.
As my knowledge and skills with proper pointer usage has proven to be extremely dangerous to a working V-TFT programs life, I will not be doing any more experiments with the code until I receive some guidance as to proper usage methods needed for these object structures.
Regards all, peace-out, Robert.
