Trying to update for playlist resize

[drewkeller]

what am i doing wrong here?
I can get the resize cursor handles for the edge resizers but the extension stays its orginal size. the resize control (non-edge) doesn't even give me the resize cursor.

[fatal error]

seemed ok to me repackaged like this, but without a skinkid.ini i couldnt fully test it

[drewkeller]

adding the extra lines to the ini file helped. it's still doing something funky though. the right and down resizers work ok but the top and left resizers are screwy.

[fatal error]

made a small edit to .ini to clear up the bugs.....i think

add this:


ExtOnTop=3
ext0after=1,2,3
ext1after=2,3
ext2after=3
ExtDrag=3

[drewkeller]

that helpd, thanks!

[fatal error]

that helpd, thanks!
anytime drew

cheers

[drewkeller]

now i'm having trouble with getting the main part of this skin resizable.

first, i want the body and ext1 to stretch together

second, i would have liked the tiled area to be on the right hand side of the volume/position sliders. or maybe stretch it the sliders so that the whole body graphic is stretched. but i can live with it the way it is if i have to.

i can't figure out what i'm doing wrong.

[fatal error]

it would require a little re-working, but a perfect example of what you want was used by regen in Digipod (playlist/encoder). at least that's what it sounds like to me.
if i've misunderstood, sorry

cheers

[drewkeller]

no, that's not really what i was looking for. i just want the body to remain the same wiidth as ext1, even while ext1 is being resized.

i think it's a question of ownership, but what i want to do requires a circular ownership. i want the body to open ext1 but i want ext1 to resize the body.

would it work if i create a dummy extension (say ext4) and have the button to open that on the body and then open ext1 indirectly?
ext4open=1>

for some reason i don't think this would work.

[fatal error]

i dont think that will work

[drewkeller]

i got something to work satisfactorily for resizing

now i'm not sure why, but when i cycle through the skin modes via the next mode button, the body decides (seemingly randomly) when i change to a different mode that it should be behind ext9. has anyone seen this before?

(file too large... download from www.drewkeller.com/download/arizona.qsf)

thanks

[fatal error]

i've seen it before, but didnt think you'd run across it

[regener8ed]

i got something to work satisfactorily for resizing

now i'm not sure why, but when i cycle through the skin modes via the next mode button, the body decides (seemingly randomly) when i change to a different mode that it should be behind ext9. has anyone seen this before?

thanks

I get this occassionally on various projects. It seems particularly likely to happen if you clear the skinpref.ini or load the skin for the very first time.

[fatal error]

i rebuilt the family how i woulda done it

all bugs seem fixed

gimme a holler if you want a copy

cheers

btw...the updated version, some of eqsets you recolored the map sections making them act weird. and the small font bmp has errant dots. both of which i fixed in my version

[drewkeller]

i'll take a look if you don't mind. you can email it to me at drew@drewkeller.com (please put [QCD] in the subject line to bypass my junk mail filter)

all of the mouseover text properly identifies the EQ channels and the sliders operate ok, but i don't use the EQ, so maybe it's the audio that's weird.

i made some changes in the family file that fixed the on top problem and also recolored the body (some buttons didn't blend correctly before). i already submitted with these changes so i'll keep your changes for the next update.

the font bitmaps were out of the font maker utility. now that you mention it, i do notice some dots on the i and the g. could be others.

[fatal error]

the font maker doesnt make perfect files all the time, but it greatly eliminates most of the work.

you misunderstood me about the eqset problem on some of the color schemes. i am referring to the eqset.bmp of a few of the colors. the map section, including the delimiter got recolored thus making them malfunction.

i sent a copy of my version. i made a ton of changes, but as i said earlier, it's how i would have done it.

[drewkeller]

this is the only skin i've released so it's not like i have a manufacturing system for them :) thanks for taking a look at it.

i had the extensions numbered weirdly out of order because older skinning standards had certain numbered extensions as fixed/unfixed.... never got fed up enough with them out of order to bother renumbering them

i see what you are saying on the eq now. i figured out it was doing that on some of the files about halfway through and must have missed fixing the eq files.

i don't understand the reason for ext5....?

i'm not quite sure why, but the opening an extension doesn't do the fade-in like it did before. not a big deal to me since i don't know how it was doing it in the first place, but still curious.

i wonder if resizing the body to the left will work now..... hmm....
i wish the skindoc was a little more specific about how the engine handles resizing. it just basically says weird things will happen and you have to test if you use discontinuous break lines.

[fatal error]

was playing with a couple other things....ext5 was part of it. aborted working on it when you posted update.