Re: Confirm Long File Name Bug in Player Object
[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 I know what you mean by 'the last one'. Finally, it is almost always a good idea to include 'Cancel' as an option in case the User made a mistake or changed their mindI would suggest... 'Are you finished with the last [specify what here]?' No/Yes/Cancel if Yes, 'Shall I clear the header?' No/Yes/Cancel OR 'Are you finished with [specify what here]? If you click YES the header will be cleared.' No/Yes/Cancel The abmiguity can be further reduced by using the verb from the question as the label for the confirmation button, e.g.: Do you can to clear the header? Cancel / Don't Clear / Clear Ever since Save dialogs started doing that support costs dropped industry-wide. :) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 this (using Thomas's idea to just re-write the question...) : S Answer Was your last transcript complete and successfully uploaded? S with Yes or No Much better. It's a single question now and presents the user with a simple yes-or-no branching point. It's clear that if the last session was complete then it doesn't matter if the buffer is cleared, and I would assume from this that pressing No would leave things as they are. As a user of your system I don't really care if the header is cleared behind the scenes or not - all I'm concerned with is whether or not I've completed the last edit. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 back again: You can to clear the head? English to French and back again: Do you put out of box to release the heading? English to Italian and back again: Inscatolate in order to eliminate the heading? English to Portuguese and back again: You tin to cancel the heading? English to French to German to English: Do you place in crate to set the title free? The last seems very zen, and I'm sure it's the key to understanding this conundrum. I shall meditate on this. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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? English to Spanish and back again: You can to clear the head? English to French and back again: Do you put out of box to release the heading? English to Italian and back again: Inscatolate in order to eliminate the heading? English to Portuguese and back again: You tin to cancel the heading? English to French to German to English: Do you place in crate to set the title free? The last seems very zen, and I'm sure it's the key to understanding this conundrum. I shall meditate on this. It's a new dialect called Sleep Deprivation. It's easy to become a native speaker: just go without sleep for two days straight and you'll be speaking it like it was your native tongue. :) -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 bit confusing to the user. Sput theTape into tTruncatedFileName S put char 1 to 13 of (item -1 of theTape) .mp3 into item -1 S of tTruncatedFileName S rename file theTape to tTruncatedFileName ... and here I would check to make sure that file tTruncatedFileName doesn't already exist before trying to rename it... Anyway, glad you found a workaround for now. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 back to me with questions I never dreamed of... In anticipation of doing more for the public in the not-too-distant future see below On Jun 25, 2005, at 5:57 AM, Mark Wieder 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 bit confusing to the user. OK I think I understand... better if the buttons describe the actions and don't just throw a boolean at the user... how about this: answer Are you finished with the last one? If so, shall I clear the header info? with Cancel or Clear Header Better? skts Sput theTape into tTruncatedFileName S put char 1 to 13 of (item -1 of theTape) .mp3 into item -1 S of tTruncatedFileName S rename file theTape to tTruncatedFileName ... and here I would check to make sure that file tTruncatedFileName doesn't already exist before trying to rename it... Anyway, glad you found a workaround for now. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 Cancel has always bothered me in contexts like this. If you are presenting two questions then there are four possible states for the user. It looks to me like you are taking care of two of those: clear header YN finished -- Y | Clear || N | | Cancel | -- If I'm the user and I'm finished with the last one, what will happen when I press Cancel? Will my changes disappear? If I'm not done what does Cancel mean? What if I'm done with the last one but I don't want to clear the header info? In this last case, I don't really know what you're intending, so I don't know if that's even an option - it may be clear from where I am in the application. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 or Yes HTH TOm On Jun 27, 2005, at 4:30 PM, Sivakatirswami wrote: 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 back to me with questions I never dreamed of... In anticipation of doing more for the public in the not-too-distant future see below On Jun 25, 2005, at 5:57 AM, Mark Wieder 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 bit confusing to the user. OK I think I understand... better if the buttons describe the actions and don't just throw a boolean at the user... how about this: answer Are you finished with the last one? If so, shall I clear the header info? with Cancel or Clear Header Better? skts Sput theTape into tTruncatedFileName S put char 1 to 13 of (item -1 of theTape) .mp3 into item -1 S of tTruncatedFileName S rename file theTape to tTruncatedFileName ... and here I would check to make sure that file tTruncatedFileName doesn't already exist before trying to rename it... Anyway, glad you found a workaround for now. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Thomas J. McGrath III SCS 1000 Killarney Dr. Pittsburgh, PA 15234 412-885-8541 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 then it was too late. Anyway, I'm using send the app to save itself now every 5 minutes and will shortly cause the whole thing to dump the .xml file one each save *and* save the transcript into a global they can revert too as a triple safety against losing work. So if my app or my rev player stand alone or their system goes up in smoke, they will have their work up to the last five minutes on the hard drive. Point: these kinds of users are very easily confused and will just stop in their tracks if things don't seem obvious. I like your 2 questions 4 states diagram. Made me think my problem is in the use of finished which is ambiquous because what it really means is a) user has completde transcription of the last .mp3 file, has proofread the text and successfully uploaded the xml file to our server here and is ready to start a new one... clean slate... b) Having done that, and downloaded some new lectures to transcribe, they are supposed to then select a new audio file to transcribe. This dialog is a fail safe to make sure they actually completed a) above before starting a new one... if they do start a new one, the data in the substack header is cleared... Also clearing the header is a really an internal maintenance thing, like wiping off the black board the next class... the students in the next class really don't need to know about that event any more than we need to tell them I am about to put empty into all the globals in this stack... [i.e. in answer to your question... no, the user would never want to retain the header info when starting a new transcript.] All we really need to do is check ask the user if they succeed with a) above and then proceed. How about this (using Thomas's idea to just re-write the question...) : Answer Was your last transcript complete and successfully uploaded? with Yes or No Sivakatirswami On Jun 27, 2005, at 11:17 AM, Mark Wieder wrote: 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 Cancel has always bothered me in contexts like this. If you are presenting two questions then there are four possible states for the user. It looks to me like you are taking care of two of those: clear header YN finished -- Y | Clear || N | | Cancel | -- If I'm the user and I'm finished with the last one, what will happen when I press Cancel? Will my changes disappear? If I'm not done what does Cancel mean? What if I'm done with the last one but I don't want to clear the header info? In this last case, I don't really know what you're intending, so I don't know if that's even an option - it may be clear from where I am in the application. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 immediate problem and by changing a few other scripts that refer to the field that contains the path to refer instead to the custom prop that contains a 32 filename... I'm good to go and I'll offer some mangoes to the Gods of the temple of Run Rev that they will fix this before I get back to building the other apps related to this project, in those contexts I definitely do not want to be changing these files names... oh...viz-a-viz the bug categorizatioin: i guess, since I *can* carry on, this is indeed not a true blocker... :-) I see what you mean... a true blocker should mean I can't do *anything* to continue. global theTape on mouseUp answer Are you finished with the last one? If so, shall I clear the header info? with No or Yes if it is No then exit to top answer file Locate the sound file you want to transcribe. with (fld localPath of stack atra-prefs /) if it is empty then exit mouseUp put it into theTape put empty into fld theTotalTime put theTape into fld soundfile set the uActualFileName of fld soundFile to theTape set the itemdel to / if len(item -1 of theTape)32 then put theTape into tTruncatedFileName put char 1 to 13 of (item -1 of theTape) .mp3 into item -1 of tTruncatedFileName rename file theTape to tTruncatedFileName put tTruncatedFileName into theTape set the uActualFileName of fld soundFile to theTape end if set the filename of player theTape to theTape clearHeader end mouseUp On Jun 24, 2005, at 7:41 PM, Dar Scott wrote: 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 the fileName of player i to aliasPaththen check player's props filename will be the original long one. It was worth a try. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 development, not at the end. If a bug's fix's being crucial in delivery makes it a Blocker, then I'll have to change a dozen of my bug entries to Blocker. I can't argue that this bug is not a blocker, only that (from my reading of the bugzilla definition) it is not a Blocker. I don't mean to belittle the bug; I'm just being legalistic about the category Blocker. Even though it is highest in some sense, it also is different in quality in that it narrows the kind of bug. Examples might be key doesn't work or can't open stack. I didn't make up the definition, so I might be way off. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 to my clients. Whether this is because of a development issue for which there is no workaround or because of a runtime issue is merely academic. If I can't get something accomplished in rev and have to switch to another tool, that's a blocker. I do have some bugs for which this is true and I have left at major instead of bumping the level because I don't have a pressing need for them to be fixed. If I did then they would be blocking me from doing what I need to do and I wouldn't have a problem escalating them. -- -Mark Wieder [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 reason or another and this prevents me from delivering my application to my clients. Whether this is because of a development issue for which there is no workaround or because of a runtime issue is merely academic. If I can't get something accomplished in rev and have to switch to another tool, that's a blocker. I guess my point is that it is not a to my mind thing. It is a matter of respecting the definition set up by Runrev. Runrev might have limited Blocker to only bugs that had to do with the color green and I would be inclined to submit to that, though I might mock it. Even so, I admit that I might be reading in something more stringent than what is there. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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, it's not like I'm messing with my clients file archive... but still I like the alias possibility. I would need that to work on both Mac and Windows... do you have a cross platform script to code an alias? thanks Sivakatirswami On Jun 24, 2005, at 2:58 PM, Brian Yennie wrote: 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 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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 like: repeat with i=1 to number of players put the fileName of player i into playerPath set the itemDelimiter to / put specialFolderPath(temporary)/(item -1 of playerPath) into aliasPath create alias aliasPath to file playerPath if (the result is empty) then set the fileName of player i to aliasPath else answer error Error Creating Alias to Media end if end repeat Untested, but hopefully helpful. I've tested that setting the fileName to an alias DOES work, I just haven't experienced the long file path bug myself, so can't say whether it cures that! HTH - Brian 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, it's not like I'm messing with my clients file archive... but still I like the alias possibility. I would need that to work on both Mac and Windows... do you have a cross platform script to code an alias? thanks Sivakatirswami On Jun 24, 2005, at 2:58 PM, Brian Yennie wrote: 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 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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 player's props filename will be the original long one. On Jun 24, 2005, at 4:26 PM, Brian Yennie wrote: 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 like: repeat with i=1 to number of players put the fileName of player i into playerPath set the itemDelimiter to / put specialFolderPath(temporary)/(item -1 of playerPath) into aliasPath create alias aliasPath to file playerPath if (the result is empty) then set the fileName of player i to aliasPath else answer error Error Creating Alias to Media end if end repeat Untested, but hopefully helpful. I've tested that setting the fileName to an alias DOES work, I just haven't experienced the long file path bug myself, so can't say whether it cures that! HTH - Brian 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, it's not like I'm messing with my clients file archive... but still I like the alias possibility. I would need that to work on both Mac and Windows... do you have a cross platform script to code an alias? thanks Sivakatirswami On Jun 24, 2005, at 2:58 PM, Brian Yennie wrote: 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 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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 the fileName of player i to aliasPaththen check player's props filename will be the original long one. It was worth a try. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 the path to refer instead to the custom prop that contains a 32 filename... I'm good to go and I'll offer some mangoes to the Gods of the temple of Run Rev that they will fix this before I get back to building the other apps related to this project, in those contexts I definitely do not want to be changing these files names... oh...viz-a-viz the bug categorizatioin: i guess, since I *can* carry on, this is indeed not a true blocker... :-) I see what you mean... a true blocker should mean I can't do *anything* to continue. global theTape on mouseUp answer Are you finished with the last one? If so, shall I clear the header info? with No or Yes if it is No then exit to top answer file Locate the sound file you want to transcribe. with (fld localPath of stack atra-prefs /) if it is empty then exit mouseUp put it into theTape put empty into fld theTotalTime put theTape into fld soundfile set the uActualFileName of fld soundFile to theTape set the itemdel to / if len(item -1 of theTape)32 then put theTape into tTruncatedFileName put char 1 to 13 of (item -1 of theTape) .mp3 into item -1 of tTruncatedFileName rename file theTape to tTruncatedFileName put tTruncatedFileName into theTape set the uActualFileName of fld soundFile to theTape end if set the filename of player theTape to theTape clearHeader end mouseUp On Jun 24, 2005, at 7:41 PM, Dar Scott wrote: 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 the fileName of player i to aliasPaththen check player's props filename will be the original long one. It was worth a try. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Confirm Long File Name Bug in Player Object
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 it plays as expected on a start player test c) now go to the finder (OSX, Tiger) and change the file name to somefoo0123435678901234567890123456789.mp3 d) now go back, set the player object to this same file which now has a file name with 33 chars... e) start player test here, the player object is now simply dead go back... truncate the file name to 33 chars... try again... now it works.. Sivakatirswami ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 player test to this file and confirm it plays as expected on a start player test c) now go to the finder (OSX, Tiger) and change the file name to somefoo0123435678901234567890123456789.mp3 d) now go back, set the player object to this same file which now has a file name with 33 chars... e) start player test here, the player object is now simply dead go back... truncate the file name to 33 chars... try again... now it works.. Confirmed, as of November last year. Also, try adding special characters to the file name, such as - or (. These broke playback for me at the time. I would set this at Blocker status because it prevents playback of otherwise playable media. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 or the whole path. Has anyone else seen this? At 02:08 PM 6/23/2005, you wrote: 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 player test to this file and confirm it plays as expected on a start player test c) now go to the finder (OSX, Tiger) and change the file name to somefoo0123435678901234567890123456789.mp3 d) now go back, set the player object to this same file which now has a file name with 33 chars... e) start player test here, the player object is now simply dead go back... truncate the file name to 33 chars... try again... now it works.. Confirmed, as of November last year. Also, try adding special characters to the file name, such as - or (. These broke playback for me at the time. I would set this at Blocker status because it prevents playback of otherwise playable media. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 24-hour recorded info hotline: 1-800-624-7671 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 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 or the whole path. Best Regards from Paris, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 ... somefoo0123435678901234567890123456789.mp3 ... here, the player object is now simply dead go back... truncate the file name to 33 chars... try again... now it works.. Confirmed, as of November last year. Also, try adding special characters to the file name, such as - or (. These broke playback for me at the time. like german umlauts and french accents... I would set this at Blocker status because it prevents playback of otherwise playable media. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com this is bug nr. 396 as of 2003-08-20 and it is still marked as NEW!? C'mon RunRev! http://support.runrev.com/bugdatabase/show_bug.cgi?id=396 Mark, i am sure you read this, this is not acceptable and a real blocker especially in non english speaking countries like germany with its lots of umlauts etc... PLEASE resolve this one as soon as possible, PLEASE!!! Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 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 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 or the whole path. Best Regards from Paris, Eric Chatonet. So Smart Software For institutions, companies and associations Built-to-order applications: management, multimedia, internet, etc. Windows, Mac OS and Linux... With the French touch Free plugins and tutorials on my website Web sitehttp://www.sosmartsoftware.com/ Email[EMAIL PROTECTED]/ Phone33 (0)1 43 31 77 62 Mobile33 (0)6 20 74 50 86 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 likely still using the FSSpec file structure with QuickTime. QuickTime 6 introduced new movie storage functions that support all of the fancy long names but the Rev code needs to be updated to determine if QT 6 is installed and then use the appropriate functions. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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. Revolution is most likely still using the FSSpec file structure with QuickTime. Exactly! http://support.runrev.com/bugdatabase/show_bug.cgi?id=396 That's exactly what Tuviah mentioned here: --- Additional Comment #1 From Tuviah Snyder 2003-08-22 21:23 --- right this is because we using fsspecs..we plan to look into fixing the 32 char filepath limitation (either use unix paths or fsrefs) in the next release. QuickTime 6 introduced new movie storage functions that support all of the fancy long names but the Rev code needs to be updated to determine if QT 6 is installed and then use the appropriate functions. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 (256 chars) and there must be other Carbon application that support long filenames. Revolution is most likely still using the FSSpec file structure with QuickTime. Exactly! http://support.runrev.com/bugdatabase/show_bug.cgi?id=396 That's exactly what Tuviah mentioned here: --- Additional Comment #1 From Tuviah Snyder 2003-08-22 21:23 --- right this is because we using fsspecs..we plan to look into fixing the 32 char filepath limitation (either use unix paths or fsrefs) in the next release. QuickTime 6 introduced new movie storage functions that support all of the fancy long names but the Rev code needs to be updated to determine if QT 6 is installed and then use the appropriate functions. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 24-hour recorded info hotline: 1-800-624-7671 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 file to it's original name.. export the matching .xml file (of the transcript and metadata from the discourse) with the long name... all doable, wish me luck! but, ideally this gets fixed on tonite's build and the next patch release that is issued every 72 hours on a cron... Sivakatirswami On Jun 23, 2005, at 10:55 AM, Peter T. Evensen wrote: 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 (256 chars) and there must be other Carbon application that support long filenames. Revolution is most likely still using the FSSpec file structure with QuickTime. Exactly! http://support.runrev.com/bugdatabase/show_bug.cgi?id=396 That's exactly what Tuviah mentioned here: --- Additional Comment #1 From Tuviah Snyder 2003-08-22 21:23 --- right this is because we using fsspecs..we plan to look into fixing the 32 char filepath limitation (either use unix paths or fsrefs) in the next release. QuickTime 6 introduced new movie storage functions that support all of the fancy long names but the Rev code needs to be updated to determine if QT 6 is installed and then use the appropriate functions. -- Trevor DeVore Blue Mango Multimedia [EMAIL PROTECTED] Regards Klaus Major [EMAIL PROTECTED] http://www.major-k.de ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution Peter T. Evensen http://www.PetersRoadToHealth.com 24-hour recorded info hotline: 1-800-624-7671 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 means it blocks development testing. The developer can temporarily shorten the names and continue development and testing until a workaround or fix is available. Or did I miss something? Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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, when the transcriber finishes work, restore the file to it's original name.. export the matching .xml file (of the transcript and metadata from the discourse) with the long name... all doable, wish me luck! Truncating and then restoring the file name might leave the name shortened on a crash or other abnormal exit, unless you do something special. Perhaps you can use a custom prop on the player and use that in all cases. The setProp handler can then check for name size and do whatever is needed. That might be creating an alias, copying the file, or (as you mentioned) shortening the name. It can also do whatever is needed to clean up after the old name. Quitting need do something simple, such as setting the custom property to empty. (I have no idea whether an alias will really work for a player.) Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 development testing. The developer can temporarily shorten the names and continue development and testing until a workaround or fix is available. Or did I miss something? Perhaps. I can see two ways of looking at this: managing your own media and managing users' media. 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. 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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object--OTHER
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 remember. tom ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 extremely upset. You are right. And at the time of my comment, I hadn't thought too much into what a workaround would be like. 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. Dar -- ** DSC (Dar Scott Consulting Dar's Lab) http://www.swcp.com/dsc/ Programming and software ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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. You are right. And at the time of my comment, I hadn't thought too much into what a workaround would be like. 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? Regards, Scott Rossi Creative Director Tactile Media, Multimedia Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Confirm Long File Name Bug in Player Object
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 one, this might be OK, but I question whether this is a valid workaround for potentially dozens of multi-megabyte files. Exactly my precise predicament potentially dozens of multi-megabyte files. How about in the range of 2000! (I'm not kidding, we have a huge audio library archival project in process...) My Audio Transcriber.rev is deployed now to about 15 people on remote locations around the world, this app downloads files from our server on the LAN in Hawaii, transcripts are done locally, these are sent back here with a POST to a CGI on our server here and later, when ready for public, transfered to our distribution web server in Connecticutt. Meanwhile I have inhouse apps in the works that will catalog and make all these sound files and their transcriptsaccessible. I set a new standard here for file names where [2-ltr abbreviation for the author-speaker]_[international-date the talk is given]_[some unique subjectwords].mp3 e.g. we record Scott Rossi describing his work flow for software development, the file is named sr_2005-06-05_RevConWorkFlowPresentation.mp3 and the XML transcript becomes sr_2005-07-23_RevConWorkFlowPresentation.xml because I got fed up with an earlier model we developed for reasons long ago for reasons I won't get into here: based on paths past/2005/July/July_23_05/sounclip.mp3 where a data base was an absolute requirement to make any sense out of these files. The new model, which may also have a database for query work, is more accessible... we need our editors to be able to simply go to the server on the LAN and make some sense out of what they see from the Finder... My whole functional spec was envisioned with the expectation that the long file name issue, was no longer an issue. A mistake on my part... a little hacking in the early stages can be really critical to the development path. I think you can see the kind of nightmare I'm headed for... Right, sure it's not a blocker, we can still develop but if x Number of hours are used to implement a workaround, instead of making progress, in my book, as a production manager for publications that must get out the door on real time schedules, that's a blocker... Sivakatirswami ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
