Re: Confirm Long File Name Bug in Player Object

2005-06-28 Thread Richard Gaskin
[EMAIL PROTECTED] wrote: answer Are you finished with the last one? If so, shall I clear the header info? with No or Yes This would confuse the hell out of me, I am afraid. What if I want to finish and NOT clear the header? The questions are not mutually exclusive. It also assumes

Re: Confirm Long File Name Bug in Player Object

2005-06-28 Thread Mark Wieder
Sivakatirswami- Monday, June 27, 2005, 6:31:36 PM, you wrote: S drive. Point: these kinds of users are very easily confused and will S just stop in their tracks if things don't seem obvious. Yes. As should we all, I think. If things are ambiguous it's time to stop and take stock. S How about

Re: Confirm Long File Name Bug in Player Object

2005-06-28 Thread Mark Wieder
Richard- Monday, June 27, 2005, 11:15:23 PM, you wrote: RG Do you can to clear the header? I figured you were maybe speaking a patois here, so I tried various translations in Google: English to German and back again: Do you preserve, in order to delete the heading? English to Spanish and

Re: Confirm Long File Name Bug in Player Object

2005-06-28 Thread Richard Gaskin
Mark Wieder wrote: Richard- Monday, June 27, 2005, 11:15:23 PM, you wrote: RG Do you can to clear the header? I figured you were maybe speaking a patois here, so I tried various translations in Google: English to German and back again: Do you preserve, in order to delete the heading?

Re: Confirm Long File Name Bug in Player Object

2005-06-28 Thread Dar Scott
Since this seems to have changed, can we get a new subject on this? -- Dar ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

Re: Confirm Long File Name Bug in Player Object

2005-06-27 Thread Mark Wieder
Sivakatirswami- Friday, June 24, 2005, 10:55:21 PM, you wrote: Sanswer Are you finished with the last one? If so, shall I clear S the header info? with No or Yes I understand the intent, but I have to say that I find two yes-or-no questions in a single answer dialog with a single response a

Re: Confirm Long File Name Bug in Player Object

2005-06-27 Thread Sivakatirswami
We appreciate constructive criticism. I'm not a trained developer, and just do the best I can... some computer savvy users take your apps and run with them... gives you the false sense that you did a great job with the UI... but I'm learning that's not true as some of my naive users come

Re: Confirm Long File Name Bug in Player Object

2005-06-27 Thread Mark Wieder
Sivakatirswami- Monday, June 27, 2005, 1:30:58 PM, you wrote: S answer Are you finished with the last one? If so, shall I clear S the header info? S with S Cancel or Clear Header S Better? I like the Clear Header. That makes it obvious what will happen if I press the button. The concept of

Re: Confirm Long File Name Bug in Player Object

2005-06-27 Thread Thomas McGrath III
Sivakatirswami, I would leave the No and Yes buttons and just change the text: answer Are you finished with the last one? This will clear the header info. with No or Yes or maybe clarify what the last one is: answer If you are finished, do you want to clear the header information? with No

Re: Confirm Long File Name Bug in Player Object

2005-06-27 Thread Sivakatirswami
basic but still intriquing discussion, tks for bearing with it. It seems overly subtle perhaps, but not really... I had a user use select her entire transcript and CUT and it disappeared... she wrote me an email asking what to do ! I wrote back... Just paste it back again... of course by

Re: Confirm Long File Name Bug in Player Object

2005-06-26 Thread Jon
Is this just a Mac problem, or is it also a Windows problem? :) Jon Sivakatirswami wrote: OK I throw in the towel... I'll rename the files for now on the users hard drive while retaining the long file name for all other processes other than simply to play the player... this solves the

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Dar Scott
On Jun 23, 2005, at 6:39 PM, Scott Rossi wrote: Even so, I think this loss of functionality qualifies as (at most) Major, in that it is a major loss of function. I understand Blocker to mean I can't develop. How is this different from I can't deliver? It blocks you up front in

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Mark Wieder
Dar- Friday, June 24, 2005, 9:25:50 AM, you wrote: DS I didn't make up the definition, so I might be way off. I don't think you're way off, but off enough to be wrong. To my mind, a blocker is I can't do xyz in rev for one reason or another and this prevents me from delivering my application

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Dar Scott
On Jun 24, 2005, at 11:20 AM, Mark Wieder wrote: DS I didn't make up the definition, so I might be way off. I don't think you're way off, but off enough to be wrong. I have a vague memory of being wrong before, so that is possible. To my mind, a blocker is I can't do xyz in rev for one

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Brian Yennie
I know this is a pretty dirty sounding workaround, but what happens if you place an alias to the file in the user's temporary files (instead of copying it there)? More work but less disk space if it works... If you want to deliver a media player now, the only way around this is to have your

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Sivakatirswami
I'm all ears... in this app, the sound file is downloaded over the net... and later thrown away... the source file is on our server and will continue to carry the long file name... so, temporarily changing the name of the file is not dangerous in this context and since we own the files,

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Brian Yennie
Sivakatirswami, See create alias - pretty easy to use. I can't promise that Rev won't resolve the alias and still have long file name problems, but it may be worth a shot. You could probably write a handler, if this works, that loops through all of your player objects and does something

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Sivakatirswami
Setting a player to the alias resolves the alias and applies the original path to the player's filename prop. So this alias option doesn't get us anything. try it... make alias of long file name.. truncate alias a back to 32 chars... set the fileName of player i to aliasPaththen check

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Dar Scott
On Jun 24, 2005, at 11:17 PM, Sivakatirswami wrote: Setting a player to the alias resolves the alias and applies the original path to the player's filename prop. So this alias option doesn't get us anything. try it... make alias of long file name.. truncate alias a back to 32 chars... set

Re: Confirm Long File Name Bug in Player Object

2005-06-24 Thread Sivakatirswami
OK I throw in the towel... I'll rename the files for now on the users hard drive while retaining the long file name for all other processes other than simply to play the player... this solves the immediate problem and by changing a few other scripts that refer to the field that contains

Confirm Long File Name Bug in Player Object

2005-06-23 Thread Sivakatirswami
Can someone quickly confirm this ( bugzilled already) ... a bit of a serious problem for me at the moment: a) get an .mp3 file... any will do. Make sure the number of chars in the file name (inclusive of extension) is 33 e.g. someFoo.mp3 b) set some player test to this file and confirm

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Scott Rossi
Recently, Sivakatirswami wrote: Can someone quickly confirm this ( bugzilled already) ... a bit of a serious problem for me at the moment: a) get an .mp3 file... any will do. Make sure the number of chars in the file name (inclusive of extension) is 33 e.g. someFoo.mp3 b) set some

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Peter T. Evensen
I am also noticing, on Mac, at least, the refusal to load images that are reference by long name. For example, a file named Critical Thinking Instructions.png will not load, but a file named Critical Thinking Instr.png will. I haven't played around with enough to see if it is the file name

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Eric Chatonet
Hello Peter, Assuming Mac OS... Critical Thinking Instructions.png is 34 chars (you have to count the extension) Critical Thinking Instr.png is 27 chars. The limit is 31 :-) Le 23 juin 05 à 21:14, Peter T. Evensen a écrit : I am also noticing, on Mac, at least, the refusal to load images

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Klaus Major
Hi all, Recently, Sivakatirswami wrote: Can someone quickly confirm this ( bugzilled already) ... a bit of a serious problem for me at the moment: a) get an .mp3 file... any will do. Make sure the number of chars in the file name (inclusive of extension) is 33 ...

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Todd Higgins
Is there a technical reason for Revolution having a 31 char limit in Mac OS X? Obviously the OS and filesystem support longer file names (256 chars) and there must be other Carbon application that support long filenames. Todd On Jun 23, 2005, at 3:25 PM, Eric Chatonet wrote: Hello

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Trevor DeVore
On Jun 23, 2005, at 12:39 PM, Todd Higgins wrote: Is there a technical reason for Revolution having a 31 char limit in Mac OS X? Obviously the OS and filesystem support longer file names (256 chars) and there must be other Carbon application that support long filenames. Revolution is most

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Klaus Major
Hi Trevor, On Jun 23, 2005, at 12:39 PM, Todd Higgins wrote: Is there a technical reason for Revolution having a 31 char limit in Mac OS X? Obviously the OS and filesystem support longer file names (256 chars) and there must be other Carbon application that support long filenames.

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Peter T. Evensen
I guess they decided not to fix it in the next release? At 03:26 PM 6/23/2005, you wrote: Hi Trevor, On Jun 23, 2005, at 12:39 PM, Todd Higgins wrote: Is there a technical reason for Revolution having a 31 char limit in Mac OS X? Obviously the OS and filesystem support longer file names

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Sivakatirswami
So, we are stuck... mmm. I guess i'll have to implement a work around to preserve the long file names in some custom prop, field or global, truncate the file name on disk... reset the player to the truncated file name... all on the fly, when the transcriber finishes work, restore the

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Dar Scott
On Jun 23, 2005, at 1:08 PM, Scott Rossi wrote: I would set this at Blocker status because it prevents playback of otherwise playable media. I don't agree with that. First of all, somebody will have a workaround command (3 minutes; 17 lines) shortly after I mail this. Second, blocker

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Dar Scott
On Jun 23, 2005, at 3:03 PM, Sivakatirswami wrote: So, we are stuck... mmm. I guess i'll have to implement a work around to preserve the long file names in some custom prop, field or global, truncate the file name on disk... reset the player to the truncated file name... all on the fly,

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Scott Rossi
Recently, Dar Scott wrote: I would set this at Blocker status because it prevents playback of otherwise playable media. I don't agree with that. First of all, somebody will have a workaround command (3 minutes; 17 lines) shortly after I mail this. Second, blocker means it blocks

Re: Confirm Long File Name Bug in Player Object--OTHER

2005-06-23 Thread Thomas McCarthy
I noticed that when I ran shell scripts to convert WAVE files to MP3, if the file name was long it wouldn't work. If I set the default folder to the location of the files, that seemed to help. I haven't experienced this bug on Windows--but maybe I had already dealt with it on my Mac? Can't

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Dar Scott
On Jun 23, 2005, at 4:38 PM, Scott Rossi wrote: Changing filenames of your own media may be acceptable but changing filenames of a users media is a really bad idea. If you change a filename and for whatever reason you are unable to restore to the original name, I can imagine the user being

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Scott Rossi
Recently, Dar Scott wrote: Changing filenames of your own media may be acceptable but changing filenames of a users media is a really bad idea. If you change a filename and for whatever reason you are unable to restore to the original name, I can imagine the user being extremely upset.

Re: Confirm Long File Name Bug in Player Object

2005-06-23 Thread Sivakatirswami
On Jun 23, 2005, at 12:38 PM, Scott Rossi wrote: If you want to deliver a media player now, the only way around this is to have your app duplicate the user's media somewhere on their drive, rename it, and then make sure to delete the duplicate when you're done. For a few files, one by