Hey there,
With this code it is possible to create dynamic scrollView masks. I manipulated the scrollView widget in a way that it automatically does the job for you. It works well with every phone on ios emulator and android emulator and of course on the corona simulator.
Please give it a try. Maybe there’s still some stuff to do but I’m quite happy with it as it is now:
Download the project here:
best regards,
Roman
This is great! Its much better than my “get your webserver to make it for you and then download it to the device” approach. Trying it now. Thanks much for sharing.
Edit : The mask created does not have black edges on the left and right which mean we can’t make it smaller than the width of the screen. Is it possible to make it so that it has black edges on left and right verticals and define a smaller than screen width? Thanks
Edit 2 : I think it might be a good option to make this a separate function that one can drop into his/her project rather than hacking into the scrollView. The way it is implemented now will require you to ‘hack’ it back each time CL updates the scrollView. If it was implemented as a separate function then it would be usable irregardless of what happens to scrollView in regular builds. Just a thought.
Great work!!!
hey there,
thanks for your feedback.
I know what you mean. The problem is that the mask which gets loaded in the widget needs to be rescaled in cases where the mask was not saved with the same resolution ( it can happen due to display.save issues, depending on the scale-mode in config.lua ).
I have to figure out how to access the mask of the scrollview after it’s been created. I don’t know if that’s possible with the way the widget is programmed now.
Also while the mask needs to be created I have to access the width of the saved mask-file to get the scale-ratio. My first attempt was to just load the image, get the width and then delete it and then load it as a mask. But that doesn’t work because Corona SDK forbidds that ( the image is already in cache and can not be used for a mask ). That’s why I implemented and portet the imagesize library from lua.
I will get into it if I have more time. Maybe someone else can figure out how to do this.
EDIT: It should not be a big problem to create black borders on the left and on the right.
I think what your looking for is the mask file by dennis97
http://forums.coronalabs.com/topic/33503-dyanmic-tableview-mask/?hl=generic_mask_width#entry185243
Example implementation (I know this is for a tableView, should work for a scrollview as well, as far as I understand it)
[lua]
– Create a tableView
local OPTIONS_LIST_HEIGHT = ccp.core.height - usableY - 20
local OPTIONS_LIST_WIDTH = ccp.core.width-20
– Create a tableView
tableView = widget.newTableView
{
top = usableY + 10,
left = 10,
width = OPTIONS_LIST_WIDTH,
height = OPTIONS_LIST_HEIGHT,
hideBackground = true,
noLines = false,
listener = tableViewListener,
onRowRender = onRowRender,
onRowTouch = onRowTouch
}
mask.applyMask({
object = tableView,
width = OPTIONS_LIST_WIDTH,
height = OPTIONS_LIST_HEIGHT
})
self.view:insert( tableView )
[/lua]
Hi Mourdos,
Thanks for the code. I just tested it. Had to rewrite it a bit. Now it works!
Going to make the whole thing a little prettier and update it later on…
best regards,
Roman
Super. Great to see the progress on this idea. Lets hope eventually CL pulls all this into the core for the widgets and we don’t have to worry about masking at all.
Well, I almost got it working for both horizontal and vertical masking, but there were some tricky issues which I had to solve and now I’m facing the fact that save.display does not always keep the size but sometimes saves more pixels then the display-group originally had. Like your imagegroup is 320 x 480 and the output becomes 320 x 481. This destroys the mask because it is not divisible by four.
it doesn’t happen often but it can happen. the funny thing about this is: the extra pixels have zero information so it is unnecessary.
I guess that this is because corona has it’s own scale-measuring and in the end things are not really pixel accurate
This is really annoying and I need a break now.
It seems like we don’t really need this because Graphics 2.0 and containers are coming out soon. I hope the widgets will be updated then too.
I agree any more effort spent on this now is most likely going to be redundant in a short while. I am hoping all widgets will be updated to make best use of new features to be introduced by Graphics 2.0. Can’t wait to see Graphics 2.0 and updated widgets.
This is great! Its much better than my “get your webserver to make it for you and then download it to the device” approach. Trying it now. Thanks much for sharing.
Edit : The mask created does not have black edges on the left and right which mean we can’t make it smaller than the width of the screen. Is it possible to make it so that it has black edges on left and right verticals and define a smaller than screen width? Thanks
Edit 2 : I think it might be a good option to make this a separate function that one can drop into his/her project rather than hacking into the scrollView. The way it is implemented now will require you to ‘hack’ it back each time CL updates the scrollView. If it was implemented as a separate function then it would be usable irregardless of what happens to scrollView in regular builds. Just a thought.
Great work!!!
hey there,
thanks for your feedback.
I know what you mean. The problem is that the mask which gets loaded in the widget needs to be rescaled in cases where the mask was not saved with the same resolution ( it can happen due to display.save issues, depending on the scale-mode in config.lua ).
I have to figure out how to access the mask of the scrollview after it’s been created. I don’t know if that’s possible with the way the widget is programmed now.
Also while the mask needs to be created I have to access the width of the saved mask-file to get the scale-ratio. My first attempt was to just load the image, get the width and then delete it and then load it as a mask. But that doesn’t work because Corona SDK forbidds that ( the image is already in cache and can not be used for a mask ). That’s why I implemented and portet the imagesize library from lua.
I will get into it if I have more time. Maybe someone else can figure out how to do this.
EDIT: It should not be a big problem to create black borders on the left and on the right.
I think what your looking for is the mask file by dennis97
http://forums.coronalabs.com/topic/33503-dyanmic-tableview-mask/?hl=generic_mask_width#entry185243
Example implementation (I know this is for a tableView, should work for a scrollview as well, as far as I understand it)
[lua]
– Create a tableView
local OPTIONS_LIST_HEIGHT = ccp.core.height - usableY - 20
local OPTIONS_LIST_WIDTH = ccp.core.width-20
– Create a tableView
tableView = widget.newTableView
{
top = usableY + 10,
left = 10,
width = OPTIONS_LIST_WIDTH,
height = OPTIONS_LIST_HEIGHT,
hideBackground = true,
noLines = false,
listener = tableViewListener,
onRowRender = onRowRender,
onRowTouch = onRowTouch
}
mask.applyMask({
object = tableView,
width = OPTIONS_LIST_WIDTH,
height = OPTIONS_LIST_HEIGHT
})
self.view:insert( tableView )
[/lua]
Hi Mourdos,
Thanks for the code. I just tested it. Had to rewrite it a bit. Now it works!
Going to make the whole thing a little prettier and update it later on…
best regards,
Roman
Super. Great to see the progress on this idea. Lets hope eventually CL pulls all this into the core for the widgets and we don’t have to worry about masking at all.
Well, I almost got it working for both horizontal and vertical masking, but there were some tricky issues which I had to solve and now I’m facing the fact that save.display does not always keep the size but sometimes saves more pixels then the display-group originally had. Like your imagegroup is 320 x 480 and the output becomes 320 x 481. This destroys the mask because it is not divisible by four.
it doesn’t happen often but it can happen. the funny thing about this is: the extra pixels have zero information so it is unnecessary.
I guess that this is because corona has it’s own scale-measuring and in the end things are not really pixel accurate
This is really annoying and I need a break now.
It seems like we don’t really need this because Graphics 2.0 and containers are coming out soon. I hope the widgets will be updated then too.
I agree any more effort spent on this now is most likely going to be redundant in a short while. I am hoping all widgets will be updated to make best use of new features to be introduced by Graphics 2.0. Can’t wait to see Graphics 2.0 and updated widgets.