Amiga-Development

Please login or register.

Login with username, password and session length
Advanced search  

News:

Created for developers of all Amiga camps

Pages: 1 [2]

Author Topic: MUI List object and checked items (CheckListView)  (Read 7343 times)

0 Members and 2 Guests are viewing this topic.

itix

  • Newbie
  • *
  • Posts: 42
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #15 on: August 15, 2015, 11:26:14 AM »

So, thinking up loud: Use MUIA_Window_Open only on the first open trigger (remove the hook once done) and for the rest of the events use MUIA_Application_Iconified ?

This could work (not sure is it called before or after iconified state) but it gets quite hacky in the nature.
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #16 on: August 15, 2015, 01:10:43 PM »

CreateImage/DeleteImage methods dont do what you think. Internally, they create and delete nothing. Instead, they call interla MUI methods (Setup, AskMinMax, Layout and Show) like they were part of the GUI. DeleteImage is doing this in reverse manner (first Hide, then Cleanup). If you are calling too late or window was iconified between there probably are some invalid pointers installed by CreateImage.
In case it interest you, i've spend some time investigating.

I (mostly) agree with what you said.

However, when i'm doing things in the right order (outputlog shows me the order in which events take place, at least according how MUI/Zune lets me believe them to be) then the Amiga version runs just fine, while the AROS version crashes _only_ when the application was iconified during a test-session. The crash-logs shows exactly why: the image pointers where rendered invalid by AROS during iconfication somewhere.

Some pictures/output/steps of what i did (for AROS) i've posted here in this post.

Quote
So, probably only way to get them working reliably for you is calling those methods from subclass (MUIM_Setup and MUIM_Cleanup preferred).
As suggested in MUI autodocs ;).

However, MUI autodocs does not explicitly state that the returned image pointer is only valid between those two events (while usually MUI autodocs does mention such things explicitly in case it is).
Sorry, that sounded way more wrong then i had intended.

I meant:
However, MUI autodocs does not explicitly state that the returned image pointer can be rendered invalid between those events.


Although no expert, my view on the case can be read in this post.


Did anybody reported yet what happens on MorphOS if you simply start the application (version 5, with images), iconify it and attempt to de-iconify it again ? Does that work without crash ? (just as it worked for me on Amiga OS 3.x)

I would be interested to know what exactly happens for MorphOS...


There is something positive about this issue though:
This matter at least shows user tolkien what can be the difference between hooking and sub-classing.

Right now i am unable to find a good hook to tap into in order to create and destroy my images and add/remove them from the List object at the correct time when these actions should happen. Currently i'm more or less escaping 'the bullet' because of the position/time i called the routines (and doing so in the right order), but that's more luck than wisdom. As can been seen when you start the application iconified and crashes (as i haven't taken that condition into account at all, in my examples)

That is a perfect example of the statement i made about hooking being bandages and sub-classing making you a surgeon  ;D

edit: corrected wrong (striped) comment
« Last Edit: August 15, 2015, 03:07:43 PM by magorium »
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #17 on: August 15, 2015, 01:17:28 PM »

So, thinking up loud: Use MUIA_Window_Open only on the first open trigger (remove the hook once done) and for the rest of the events use MUIA_Application_Iconified ?

This could work (not sure is it called before or after iconified state) but it gets quite hacky in the nature.
Alas, the state is also changed after the fact (comments prefixed with //).

a small sample of events:
Code: [Select]
leave - ListItemClicked()
// here i pressed the zoom button
ThisWindow_CloseHookFunc
ThisApp_HideHookFunc
// here i double clicked the AppIcon on the workbench
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
enter - ThisList_DisplayHookFunc
leave - ThisList_DisplayHookFunc
ThisWindow_OpenHookFunc
ThisApp_ShowHookFunc
// the window opened and i clicked an item in the list
A list item was "clicked"

Meaning: back to the drawing board again ;D

I have understood what you said itix, and i might be pig-headed  :P, but really would like to try to find a way to make things more reliable without the need to subclass -> i can always do that later at any given time.

Thank you for your input !
Logged

tolkien

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #18 on: August 16, 2015, 06:53:10 PM »

Sorry for the delay. Need more hours a day. Summer in Spain is a complicate thing! ;)
I have tested version 5 in MorphOS, iconify it, de-iconify and works well, no crash.
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #19 on: August 17, 2015, 12:00:01 AM »

Thank you very much for the report tolkien, i really appreciate that.

Don't you worry about the delay. Unfortunately, i know all to good that 24 hours is not enough for a day.

Whoever invented that 24 hour/day schedule must have been a complete lunatic  ???

Summer in Spain is complicated ? Now you got me all wondering about that. Isn't it just like here: going to a beach, sitting in the sun drinking beer all day long ?  :D
Logged

tolkien

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #20 on: September 06, 2015, 11:20:25 PM »

I'm not in Mars. I have recoding a few thing to use hooks instead Return_ID, reading, drinking beer and working 10 hours a day.
I'm having troubles understanding how hooks use their parametres to make work MUIA_List_ConstructHook and MUIA_List_DisplayHook.

Documentation about hooks are very limited but I'm near to resolve them.
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #21 on: September 07, 2015, 01:47:30 AM »

a normal hook entry function has the form:

Function HookFunc(Hook: PHook; Obj: APTR; Msg: APTR): LongInt;

where
- hook is a pointer to struct hook
- obj is a pointer to the current object
- msg is pointer to a specific message being invoked on the object.

But, the displayhook is declared a little different:

function Displayhook(hook: pHook; ReturnData: PPChar; Element: Pointer): ULONG;

where:
- hook is a pointer to struct hook
- ReturnData is a pointer to a pointer of char (actually array of char)
- Element being the current element in the list

When using a single string (default) the ReturnData is a pointer to a char (a simple string) which is used as string actually being displayed on the screen in your listview.
The Element is in that case the current element in the list that needs to be displayed being also a pointer to a char (array).

What makes the displayhook more difficult to understand is the fact that a list(view) can have multiple columns. In that case the ListElement is not a single
string but rather that of a single item in the list (whatever you provided it). The returndata then becomes an array to an array of char (usually typed as pointer to pointer of char in c programming language).

If you do not return the correct number of pointers to char (which must match the number of columns), the displayhook will 'crash' when running (at least on AROS it did for me).

If you took the liberty of creating your elements using the construct hook then the Element variable of the displayhook will be a pointer to whatever memory you allocated (and filled with data) in the constructhook.

In the constructhook you can create any data structure you want to represent your element in the list. That's why you allocated the memory for your listentry in the constructhook. You return the pointer to the memory you allocated, and if you filled it with actual values, then you can use that pointer to access the data again in the displayhook.

Things can get more complicated when using column titles as well (as some of the data pushed to the displayhook can be nil/zero (in which case it represents the title being parsed).

I'm currently in the process of pushing Krashan's examples (rewritten in free pascal, translated into english) to github, but doing so in a regular slow pace. In Part 8 and Part 9 the listview is being handled extensively.
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #22 on: September 12, 2015, 03:10:09 PM »

regarding the list constructhook

The hook function itself has the following form:

function ConstructHook(hook: pHook; pool: APTR; Element: Pointer): ULONG;

where:
- hook is a pointer to struct hook
- pool is a pointer to a memorypool, you can use it to 'add' memory to the pool that needs to be allocated (if any)
- Element being the current element in the list (f.e. data inserted with MUIM_List_Insert)

It's a little out of scope to get into the inner workings of pools, but you could perhaps compare it a little as a closet with different compartments.
The closet being the complete pool and the individual compartments being 'puddles' of small allocated memory regions that belong to the 'pool'/closet.

More information about memory pools can be read here.

Now, in the List's constructhook you _can_ (not must) use the memory pool for whatever you see fit. If you need to allocate a dynamic structure that needs to be displayed in the list for example.

In my CheckListView example i didn't use the construct hook at all, because i used static data which memory allocation is handled by the compiler -> that was a design decision on my part.

No matter what, in case you used the pool variable to add your dynamically allocated memory using AllocPooled() (f.e. to be able to hold an single element of your structured data), then you are obligated to use the destructor hook to free up that allocated memory again (using FreePooled() for each item being 'handled' by the destructor ).

The element variable, is the current listitem being 'handled' by the constructor. Usually this is a pointer to char(array), but it can be a pointer to a structure or even a simple number. In theory it can be anything you want it to be, in practice it's often (and by default) just a simple string.

Important in the constructhook is the fact that the returnvalue of the construct hook that you have returned (usually the pointer to the AllocPooled memory after you filled it with your structured data) is being used by the list to be passed along to the displayhook.

As can been seen in my previous post (about displayhook), that returned pointer corresponds to the element variable in the displayhook.

Because you were responsible for allocating the memory and fill it with some sensible data, you actually know what the structure of that data is and you can use it in the display hook to do with that data whatever you want to do with it.

For example, lets say you have the following structure (just 4 simple strings, occupying 4*4 bytes = 16 bytes of memory on a 32 bit machine):

Type
PMyData = ^TMyData;
TMydata = Record
  SomeData1: PChar;
  SomeData2: PChar;
  SomeData3: PChar;
  SomeData4: PChar;
end;

You could use the constructhook, using AllocPooled() to allocate the 16 bytes, fill the pointers to the the strings with some valid data and return the pointer you got from AllocPooled().

Once you have the displayhook in place it will pass along that pointer as element variable and you can 'extract' the data from those 4 pointers to actually retrieve the strings. Those strings could then be used to  be returned in the displayhook so that the list actually display those strings.

How the list displays those strings is also up to you. You could concatenate these 4 strings and display them as a single string in the list, but you could also 'divide' them using separate columns (using columns is another topic on it's own).

The Destructhook would also pass along that same pointer (for each dynamic allocated structure) so that you can use it to neatly free the memory again using the FreePooled() function.

PS:
The examples for parts 8 and 9 of Krashan's MUI tutorial are now in place, so feel free to browse around and see if those examples make any sense to you. In case you have questions then please feel free to ask.

PPS:
Also for those that know, in case i have explained something not quite correctly, please feel free to correct -> i'm still learning
Logged

tolkien

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #23 on: September 13, 2015, 10:41:10 AM »

Thanks so much magorium.
This kind of info is very importante if we want future coders in our community.
As I said in irc, I have it working. Need to try and clean a fewbthing but It works.
I'm so happy!
Thanks again!
Logged

magorium

  • Full Member
  • ***
  • Posts: 221
  • Programming is an art form that fights back
    • View Profile
Re: MUI List object and checked items (CheckListView)
« Reply #24 on: September 14, 2015, 02:34:47 AM »

hi tolkien,

thanks for reporting that you got things to work. I am happy for you   :)

I'll try to improve things for the checklistview, but i'm currently a little busy finishing the tutorials and have some other stuff to take care of first.

You're more than welcome, and please feel free to bug me when you run into issues.
Logged
Pages: 1 [2]