Zugg Software :: View topic - [3.18b-3.19e]BUG: %comcreate issues **FIXED**

Posted: Thu Jun 03, 2010 11:20 pm

In 3.18a and previous:

Posted: Fri Jun 04, 2010 1:03 am

I'm not familiar with the CDO.Message object. Is there some code you can show that will let me determine when it's working correctly? Like is there some properties that I could display with #SHOW to see what is working and what it not? Your code above didn't give any error, but it didn't do anything else either.

Posted: Fri Jun 04, 2010 1:24 am

Posted: Fri Jun 04, 2010 11:05 pm

Any possible information on this? I'd hate to have to resort to actually creating logs for them, then emailing them to myself (new email in each folder keeps me abreast as to what has been posted, etc).

Charneus

Posted: Sat Jun 05, 2010 10:51 am

Yeah I tested it and the first error message up was that the sendusing was invalid so this suggested to me that

#VAR ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/sendusing").Value 2

was no longer working. I edited it and used

ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/sendusing").Value = 2

instead which then made it past this line and the next error message up was from or sender fields missing. So I went through the whole script changing the necessary parts

Posted: Sat Jun 05, 2010 10:57 am

This will obviously get you up and running but there is still a bug in the SuperObject when trying to use the #var syntax as opposed to the a = b syntax for com objects, possibly only those that have many nested properties.

Posted: Sat Jun 05, 2010 11:05 am

Posted: Sat Jun 05, 2010 1:22 pm

I had tried that earlier myself, but after copying/pasting your changes, I tried running it again, only to get:

Posted: Sat Jun 05, 2010 1:43 pm

It definitely worked for me as posted. I'll follow up through PM so as not to clutter this confirmed bug report.

Posted: Sat Jun 05, 2010 5:42 pm

Definitely let me know what you find on this. If it's just a bug with #VAR not handling COM again, then let me know.

But some comments:

1) No, there is no way to "look inside a COM variable to see what is stored". COM has no type of general query mechanism like that, except for type libraries which not all COM objects support. So all CMUD knows is that "there is a COM object stored here". CMUD used to try to keep track of the original script text that stored the value, but that proved too difficult and unreliable. So now CMUD just says "" since that's all it really knows.

2) Nobody has mentioned this yet, but it's bound to come up at some point: Do NOT attempt to store COM variables within a string list or database variable. For example, DO NOT do this:

var.key = %comcreate(...)

The json tables only store primitive values (strings, integers, float) and other tables. They do not store the data type used in Delphi/Windows to store COM variable references. Only top-level CMUD variables can store a COM variable reference. This never worked in old versions either, so it's not a big deal, but just wanted to be clear about it.

Posted: Sat Jun 05, 2010 8:11 pm

Taz's solution above fixed it, however...

Every time I reload the session, the alias 'sendnote' needs to be deleted and created again for it to work properly... Not sure why that is... The fix was to import it from above, then force a save by inserting a space (he did it before the first " on the 3rd line), and then deleting that space. Then the alias worked perfectly.

Charneus

Posted: Sun Jun 06, 2010 4:00 pm

Yep it is a very odd one indeed. It doesn't work immediately on import. Correct compilation of the sendnote alias seems to rely on there being the two COM object variables already existing. I'll attempt to create a video of the process so you can see what I mean.

Posted: Sun Jun 06, 2010 6:54 pm

Click the image below for the video. It takes a while to load or it did for me, seemed to have buffering issues but bear with it, if you make it full screen you can figure out what I'm doing you might need to crank the volume to hear me though.

Below is the script that I pasted, you will need to change edit me to the correct values for Gmail. If you don't have a Gmail account then I suspect you will be okay if you use your Zuggsoft address but you will most likely need to change @Authenticate to 0 and @SmtpServerPort to 25.

<alias name="sendnote" copy="yes">
<value>#VAR MsgObj %comcreate("CDO.Message")
#VAR ConfObj @MsgObj.Configuration
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/sendusing").Value = 2
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserver").Value = @SmtpServer
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/smtpserverport").Value = @SmtpServerPort
#IF (@Authenticate) {
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/smtpusessl").Value = True
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/smtpauthenticate").Value = 1
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/sendusername").Value = @SendUsername
ConfObj.Fields("http://schemas.microsoft.com/cdo/configuration/sendpassword").Value = @SendPassword
}
#CALL @MsgObj.Configuration.Fields.Update
MsgObj.To = %1
MsgObj.From = %expand(@DefaultFrom, 1)
MsgObj.Subject = %2
MsgObj.HTMLBody = %3
#LOOP %numitems(%4) {#CALL @MsgObj.AddAttachment(%item(%4, %i))}
#CALL @MsgObj.Send
#VAR MsgObj {}
#VAR ConfObj {}</value>
<notes>sendnote "to address" "subject" "text" "attachments"</notes>
</alias>
<class name="CDOEmail" copy="yes">
<var name="Authenticate" type="Integer" copy="yes">1</var>
<var name="DefaultFrom" type="Literal" copy="yes">edit me</var>
<var name="SendPassword" type="Literal" copy="yes">edit me</var>
<var name="SendUsername" type="Literal" copy="yes">edit me</var>
<var name="SmtpServer" copy="yes">smtp.gmail.com</var>
<var name="SmtpServerPort" type="Integer" copy="yes">465</var>
</class>

Posted: Mon Jun 07, 2010 5:38 am

Interesting... I was able to create a bug report with this, so hopefully this will help you determine what the problem is. The way I got the bug report was by selecting the alias, right-clicking, then choosing 'Execute script.' Enjoy!

Posted: Mon Jun 07, 2010 10:31 am

The compiled code for the third line of the sendnote alias when the session has just been loaded.

0200 STR 'ConfObj'
0216 MAKEVAR
0220 STR 'Fields("http://schemas.microsoft.com/cdo/configuration/sendusing").Value'
0300 INT 2
0308 ASSIGNPROP 0

The compiled code for the third line of the sendnote alias after it has been run once, the COMObject vars exist and the space backspace trick is used.

0200 STR 'ConfObj'
0216 MAKEVAR
0220 LITERAL "http://schemas.microsoft.com/cdo/configuration/sendusing"
0284 STR 'Fields'
0300 DOT (1)
0308 STR 'Value'
0324 INT 2
0332 ASSIGNPROP -1

Posted: Mon Jun 07, 2010 5:22 pm

Thanks for all of that extra info Taz. It definitely looks like the parser is checking to see if a COM variable already exists when trying to compile the script, which is a problem. I'll try to track this down and will let you know if I need more info.

Posted: Wed Jun 16, 2010 5:32 am

This still continues to be an issue in 3.19e, though the original method of fixing it has changed. Now it appears that you have to keep the space instead of backspacing out of it.

Not sure what the problem is overall, but here's an alias I created to test it:

Posted: Wed Jun 16, 2010 4:30 pm

The "fix" in previous versions was to the

Posted: Wed Jun 16, 2010 6:46 pm

Ah, forgot to see if #VAR works yet.

But yes, that's exactly what I'm saying regarding the space. The alias I posted does not have a space between the ( and the ", so if you run it, it does not work at all. However, putting the space between the ( and the " for that line alone (I've tried it with other lines, and it still fails), it works.

Charneus

Posted: Wed Jun 16, 2010 7:35 pm

I cannot reproduce this. Can you go into the Compiled Code for your script and see exactly what is different there when you add the space or not?

Posted: Wed Jun 16, 2010 8:35 pm

Odd. I think that I have found what the problem is, am able to reproduce it on my end, then when I go back to test it again, it doesn't break. This is even after testing it several times (prior to posting) to see if it exhibits the same behavior each time, which it did for me. Today, though, it seems like it's a 'first time compilation' problem, and it seems that it only happens when you do this:

1. Create an untitled session.
2. Go to Settings, then make a new alias called test
3. Paste the following in the value:

Posted: Wed Jun 16, 2010 10:25 pm

Which one of those cases actually works, (4) or (6)? I'm hoping that the compiled code in (6) is the one that actually works, but let me know.

Posted: Wed Jun 16, 2010 10:35 pm

Whoops. Should have mentioned that. Yes, step 6, the case actually works. Step 4, the case does not work.

Charneus

Posted: Wed Jun 16, 2010 10:39 pm

OK, cool, I think I found the problem then.