Oh, and no, we don't receive anything from Microsoft at this time.
AFAIK, once PS2007 is Vista certified we will receive reports but I cannot tell yet how useful that will be.
So if you discover anything we should investigate it is far more helpful and faster to report it here.
Thanks,
Alex
WSF workspace
Forum rules
DO NOT POST SUBSCRIPTION NUMBERS, LICENSE KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
DO NOT POST SUBSCRIPTION NUMBERS, LICENSE KEYS OR ANY OTHER LICENSING INFORMATION IN THIS FORUM.
Only the original author and our tech personnel can reply to a topic that is created in this forum. If you find a topic that relates to an issue you are having, please create a new topic and reference the other in your post.
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
WSF workspace
Hello again, Sherlock - this is Dr. Watson. We got a new case for you.I was just testing some sample, and decided to clean up a WSF file when I stumbled upon another exception. Same build as in the OP.We're able to reproduce it 100% of the times if I follow a specific procedure.1. Remove the "Classes (Embedded)" script2. Remove the "dic" reference3. Crash.(Oops, I tried to use the "File Upload" function from a FF 2.0.0.7 browser, with very little success.)Microsoft VBScript runtime error '800a0046'Permission denied/forum2/functions/functions_upload.asp, line 688Instead I have emailed you the file - to the support - with a Subject tag of "Dr. Watson, for Mr. Holmes".JPG's to illustrated the procedure has been attached:
WSF workspace
And oh, I appreciate your input on how you prefer to get the bugreports, Alex I'm also very pleased with the way you folks over at Sapien handles the reports - swift response. Which is the primary interest of the reporter.Well, together with getting the bugs ironed out of course. I hope to be able to put in a couple of orders the coming week, I just need to get an approval from my superiors.Keep up the good work - and I hope to see a fixed build soon(tm).
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
WSF workspace
Thanks, that was a good one. No idea how that one got through.
Anyway, fixed and thanks for the detailed info.
Alex
Anyway, fixed and thanks for the detailed info.
Alex
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
WSF workspace
Thank you very much Alexander.
Unfortunately I have another one for you. I assume it's so easy to replicate that I wont send you any detailed explanation this time, just try the following:
Issue: F3 to repeat search may fail when running multiple instances of PrimalScript.
Again - same build + enviroment as in the OP.
1. Options, Application->General: Disable "Allow only one instance". Hence you are allowed to run multiple instances.
2. Open a WSF file with some sample code.
3. Start a new instance of Primalscript - open an additional WSF file in the new instance.
You should have two different instances running now - each with a different WSF file.
4. in instance one (or two) - mark some code / keyword - and press CTRL-F. Try to use F3 to repeat the search.
5. In instance two (or the other) - mark some other keyword - press CTRL-F to search. Use F3 to do the same.
6. F3 will fail to "repeat search" in one of the instances - not sure if it's the first or second which fails, but the F3 feels "disabled".
The other instance may allow the F3 to work - or may fail as well.
If you're not able to repeat it, let me know - and I'll try to come up with a more exact procedure to replicate the bugger.jonc2007-10-01 03:52:37
Unfortunately I have another one for you. I assume it's so easy to replicate that I wont send you any detailed explanation this time, just try the following:
Issue: F3 to repeat search may fail when running multiple instances of PrimalScript.
Again - same build + enviroment as in the OP.
1. Options, Application->General: Disable "Allow only one instance". Hence you are allowed to run multiple instances.
2. Open a WSF file with some sample code.
3. Start a new instance of Primalscript - open an additional WSF file in the new instance.
You should have two different instances running now - each with a different WSF file.
4. in instance one (or two) - mark some code / keyword - and press CTRL-F. Try to use F3 to repeat the search.
5. In instance two (or the other) - mark some other keyword - press CTRL-F to search. Use F3 to do the same.
6. F3 will fail to "repeat search" in one of the instances - not sure if it's the first or second which fails, but the F3 feels "disabled".
The other instance may allow the F3 to work - or may fail as well.
If you're not able to repeat it, let me know - and I'll try to come up with a more exact procedure to replicate the bugger.jonc2007-10-01 03:52:37
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
WSF workspace
We had some reports about the find enabling item and AFAIK this is already adressed. I am not sure if this really has anything to do with running multiple instances, but I'll make sure the developer working on this will have a look.
Alex
Alex
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.
WSF workspace
New crash. Able to replicate the situation again.
I dont know if this is one of the exception that you have already trapped, but here we go.
Attachment (The WSF and some Images to illustrate the problem is being sent by mail).
1. Open the "Sync.WSF"
2. Rightclick the "LibFile (Embedded)" script, and try to move it up.
Maybe relevant:
Note that the "above script is empty" - and that "Sync.WSF" and it's embedded scripts have gone through several renames (of the embedded-Names) and cleanup of old code.
3. Crash.
Again - I've sent you the specifics over email, Subject:
"Another assignment for Mr. Holmes"
I dont know if this is one of the exception that you have already trapped, but here we go.
Attachment (The WSF and some Images to illustrate the problem is being sent by mail).
1. Open the "Sync.WSF"
2. Rightclick the "LibFile (Embedded)" script, and try to move it up.
Maybe relevant:
Note that the "above script is empty" - and that "Sync.WSF" and it's embedded scripts have gone through several renames (of the embedded-Names) and cleanup of old code.
3. Crash.
Again - I've sent you the specifics over email, Subject:
"Another assignment for Mr. Holmes"
WSF workspace
Ah, I forgot to mention - the error may elude you if you keep your Mouse-cursor within the PrimalScript interface - after step 2, before step 3.
Sometimes when I tried to replicate the error I had to
- hover the cursor over a random Windows Explorer window.
- Switch focus over to other windows.
But I managed to get the crash even without switching windows.jonc2007-10-03 06:47:38
Sometimes when I tried to replicate the error I had to
- hover the cursor over a random Windows Explorer window.
- Switch focus over to other windows.
But I managed to get the crash even without switching windows.jonc2007-10-03 06:47:38
- Alexander Riedel
- Posts: 8488
- Last visit: Tue Apr 16, 2024 8:42 am
- Been upvoted: 37 times
WSF workspace
I think that is just a manifestation of the previous problem.
I'll check some more, but a preliminary test shows no crash.
Essentially moving a script up is like deleting it and adding it at a different location. A bug in deleting embedded scripts caused your first issue and it is just doing the same thing here.
I'll check some more, but a preliminary test shows no crash.
Essentially moving a script up is like deleting it and adding it at a different location. A bug in deleting embedded scripts caused your first issue and it is just doing the same thing here.
Alexander Riedel
SAPIEN Technologies, Inc.
SAPIEN Technologies, Inc.