Forum Replies Created
-
AuthorReplies
-
Hi. We have this problem as well. Can you send the Registry information please.
Thanks
Simon
Further to my previous message I have found a solution of sorts. At least I think so.
Basically my ActiveX sets and release TopMost as described before – then I use a DoEvents and a SetForegroundWindow in the Formativ applet just before it exits.
This keeps the window on-top and focused.
I’ll still prefer to make the API calls from Formativ as it would be cleaner. Is that possible?
Thanks
Simon
August 24, 2006 at 2:59 am in reply to: Clearing the mouse/keyboard buffer after displaying a form #7710The .ModalResult property/method does the trick!
My Please Wait form now prevents interaction with Groupwise, runs my applet and then goes away. Just what I wanted.
Thanks
Simon
August 23, 2006 at 10:04 am in reply to: Clearing the mouse/keyboard buffer after displaying a form #7712Hi
Thanks for the information. I have experimented some with modal/modeless forms in Formativ but can’t quite get them to waork as I need. I’ll explain what I am doing, maybe that will help.
I have two processes to get through in my applet.
The first is a test against a particular mailbox looking for a particular email. This is all handled in Formativ and takes about 2 seconds.
The second process only happens if the first process succeeds (if it doesn’t the applet displays a msg and exits). This process creates an object against my custom VB ActiveX EXE and calls a function therein. This process takes about 2 seconds to get started (creating/calling the object). At that point a form (VB form) is displayed and the user completes this. The applet code execution waits until the VB function completes.
Since processes 1 and 2 take 4 to 5 secs to get to the point where the VB form is displayed I display a modeless “Please Wait” dialog right at the start of my applet and only hide it just before displaying the VB form.
In principle this works fine. However if the user clicks around the edges of the Please Wait form, or around the edges of my VB form then those clicks are stored up and passed to GW once the applet completes.
Also, a lot of the users are keen on double-clicking the toolbar button (a formativ button) to start the applet in the first place. This means the second click waits until the whole applet has completed before being triggered – it then fails because the email has already been ‘logged’ (the purpose of my applet). I realise this is a training issue but some people just don’t do as they’ve been told.
—
Version two of my applet was to try and use a modal form. The way I tried to do this was as follows …
Create a Please Wait form.
Add a Timer to it that is enabled and has an interval of 100 (0.1sec)Add a sub for the Timer’s event that …
1) switches the timer off so it can only run once
2) triggers my main applet – the Please Wait form is hidden in this applet but is still running
3) unloads the Please wait Form once the applet has completedIn principle this works better. The Please Wait form won’t allow clicks to be directed at GW. Nor will any be done whilst the VB form is up. Double clicking the Applet’s toolbar button doesn’t start it twice. All perfect.
The one problem I have is “3)” above – I can’t work out how to get rid of my Modal form. In VB, a modal form ceases to be modal when it is hidden with the .Hide method. In Formativ this justs gets me locked out as I have a form I can’t get to to shutdown!
Is there a way of instructing the form to stop running?
I realise I could have a OK button and change the Please Wait to say ‘Log Completed’ or something but I’d rather not. They know they’ve logged it because they just filled in the form, another dialog to say OK to would be very annoying.
I am running all this is the Creator by the way, the finished applets go out as FlexaLocked. Does that change their ‘form’ behaviour at all?
Thanks
Simon
July 11, 2006 at 6:26 am in reply to: Formativ API – testing for Formativ being present and active #7675The string returned when Formativ fails to find the applet is …
<?xml version=”1.0″?>
<api-response><request-processed>false</request-processed><request-return-value>Missing Key.</request-return-value></api-response>Not sure how the key could be missing? The code is the same for all machines.
Thanks
Simon
Hi
I have run your test (as best I can) and it does work that way.
However, that is not how we create new users. We have (unsurprisingly as we are using Groupwise) Netware servers and users connect via a Netware Login.
If I login as a Netware user that is not already a Windows user on the box then, once Windows has settled down, I start Groupwise and Formativ is not present
—
The Netware tool we are using to create users is called Dynamic Local User Policy
After successful Netware login this creates a Windows user account with Administrator rights using the Netware credentials
Our servers are Novell Netware 6.0 or 6.5 (we have 3 and a user can connect to any of them, they don’#t get to choose)
Thanks
Simon
Hi
I have been testing this further and have now released 2.0.1 to all our users. I intend to use the new API feature as a test for Formativ being present and the applets being there.
Having messed around with various machines and logins I have discovered the following …
Running the install with all_users does seem to work for any user that had already previously logged into a PC and therefore had a Windows profile.
Any fresh users to a machine do not get Formativ and the installation has to be re-run.
—
Adding the key to the Local_Machine hive doesn’t seem to do anything. The export of my test machine’s key is below …
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWARENovellGroupWiseClientThird Party]
“DLL1″=”C:\Program Files\Advansys\Formativ\TokenBlocker.dll”I did discover the key had ‘odd’ permissions when it first went in (created by a VB app) but having corrected the permissions to Read/Full control for everybody (on the Third Party key) and rebooted, it still ignores my case-study user.
The only thing that distinguishes this user from any other on the PC is that his profile was created after the Formativ installation was done.
I am sure that if I run the installation again he will suddenly have Formativ attached to his Groupwise, however I am running out of practise logins so I would rather keep him broken and find a better way to fix him than a re-install.
All users are local admins on our PCs.
—
This problem is becoming a serious pain because as new people join, or as old PCs are “handed down” when new ones arrive, we are getting profiles that don’t acknowledge Formativ.
The user may not even realise this at first because the system concerned needs Formativ running in order to interact with the user.
Thanks
Simon
Thanks for confirming the details.
A preliminary test shows that this works so we will experiment a bit further and then if all is OK make the change to all the PCs
Thanks
Simon
Thanks for the reply.
It would certainly be easier to have a Local_Machine setting but I didn’t know if Groupwise would bother to read it if I tried that! Or worse it would have negative repercussions.
If I correctly understand your reply, I should be adding the following …
Key:=Third Party
Value:=DLL1=”C:PROGRA~1AdvansysFormativTokenBlocker.dll”to
HKEY_LOCAL_MACHINESoftwareNOVELLGroupwiseClient
Having looked at that area of the Registry I don’t see many other keys at the Client level. It goes “Client” then there is only “5.0” under it. Within “5.0” there are various Token related keys, e.g. AddToFolderListToken, AttachToken, etc.
I was expecting it to look something like the Current_User hive to be honest. Bit worried about getting this right now.
If you could just confirm the exact key and value settings, perhaps by posting the content of the relevant Registry export for a correctly configured machine, then I’ll duplicate it here and let you know how it goes.
Obviously a new version of the install will be useful but I have to do various tests before I can let 2.1 out anyhow so for now I’d like to focus on getting 2.0 to be independent of the user.
Thanks
Simon
Thanks for all your replies
MA:
That test was very helpful and something I should have done myself – thanks!Integration with the main toolbar I’d tried and although the button does appear down on the Quickviewer’s toolbar it’s also on the Groupwise Main toolbar which I don’t really want.
I was hoping to get the button to appear on the ‘item context’ toolbar of the Quickviewer which is over to the right by default. Doesn’t look like Formativ can do that so I’ll just have to disappoint Quickviewer users.
Support:
The test for Shared status is tidier than mine, thanks, missed that one in the API help.I do realise the API isn’t your responsibility but in this case it was the connection between Formativ’s events and the current folder/message I was struggling with.
Once I have got the object I want; be it message, folder, or whatever; I am usually OK with following the API through. Its getting to them in the first place and being sure I have the right one!
Still, by a combination of randomly changing things, helpful input from yourselves/others on this site, and coffee I now have an applet that is mostly behaving and can cope with various shared folder scenarios.
Thanks again
Simon
OK. Some further testing has thrown up the following …
1) The line that fails is
Set oMsg = Client.ClientState.CommandMessage
It fails despite the On Error arround it. Since it never seems to get the message from this line I have removed it. The ‘Groupwise.ItemMessageIDFromView()’ is now used as the source of the opening email.
2) The application level event of OnItemRead causes Groupwise.ItemMessageIDFromView() to fail when used against the Shared Folder’s messages collection.
Using the email level event of OnOpen doesn’t seem to suffer from this problem.
3) The Catastrophic Failure message has the same title as the access violation – Sorry, the applet could not be executed. The message is from Formativ, or at least passed through by Formativ.
—
Now I know what to avoid doing I can probably do so, hopefully it won’t limit the actual development.
A few questions …
A) Is it better (faster) to get a message using the GetMessage( <id> ) function at Account level or by using the SelectedFolder.Messages( <id> ) function.
Some of our users will happily harbour thousands of emails in any one folder so I need to know which method is least likely to be affected by numbers of emails. Logically I feel it ought to be the Account level one but am not sure.
B) Is there any difference between the OnItemRead and OnOpen events?
What happens if someone is using the Quickviewer. Do they still get an event?
C) Is it possible to integrate my Applets with the toolbar in the QuickViewer. They get the standard Reply/Forward buttons but not my additional ones.
Thanks
Simon
Having altered my coding a little I now have …
Set oAcct = Client.ClientState.CurrentAccount
On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0If Not IsObject(oMsg) Then
‘Check to see if the message is actually in a shared folder owned by someone else
‘If not then …
If Client.ClientState.SelectedFolder.Owner.DisplayName = oAcct.Owner.DisplayName Then
On Error Resume Next
Set oMsg = oAcct.GetMessage(Groupwise.ItemMessageIDFromView())
On Error Goto 0
‘If so, get the message from the folder itself
Else
On Error Resume Next
Set oMsg = Client.ClientState.SelectedFolder.Messages(Groupwise.ItemMessageIDFromView())
On Error Goto 0
End If
End IfIf IsObject(oMsg) Then
MsgBox “S4”
< code inside loop goes here >
End If
—
I can’t do anything about the ‘memory leak’ so am just trying to get msgbox S4 to fire.
If the chosen email is in a Shared folder I don’t own then I would expect my oAcct.GetMessage to fail since the message isn’t strictly speaking in my mailbox anymore.
What I am doing above is testing ownership of the folder and reacting accordingly.
Not shared means use GetMessage, shared means get the message from the folder itself.
However, although this makes S4 appear OK any attempted use of the oMsg variable then causes a ‘standard’ Formativ error of “Object required: ‘oMsg’ at line 38, column 6”
Line 38 is the next line to use oMsg after the IsObject(oMsg) test.
Further investigation tells me that the line
Set oMsg = Client.ClientState.SelectedFolder.Messages(Groupwise.ItemMessageIDFromView())
is failing in a weird way. The Groupwise.ItemMessageIDFromView() part errors, creating a ‘token execution failed’ message but the oMsg object is at least partially created to pass the IsObject test?
The Groupwise.ItemMessageIDFromView() call works fine when the message is in my mailbox and I’ve used this same technique in another applet and it worked fine so I don’t get how it’s going wrong here.
How do I get the message if I can’t tell which message has been opened?
This problem is affecting several PCs, not just my Creator one. The applet is meant to test an opened email to see if the user has an action against them but currently it doesn’t get that far.
Thanks
Simon
Thanks for the replies. The information has proved very useful.
I removed/replaced the Integrations as described and the simple act of doing so reminded me that one of my applets does fire on the Open event. Doh! Haven’t changed this one in ages though which is why I was ignoring it. I guess it’s always been busted for shared folders (no other folders have caused problems) but it hasn’t been apparent until now.
The extra information about the Trace facility is very handy, I have been ruing Formativ for a lack of runtime debugging and using message boxes instead – which sometimes ruins the test in itself. I shall get the third party tool at once!
For this test msgboxes worked fine, the suspect code is as follows
Dim oMsg
Dim oAcctmsgbox “s1”
Set oAcct = Client.ClientState.CurrentAccount
msgbox “s2”
On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0
If Not IsObject(oMsg) Then
On Error Resume Next
Set oMsg = oAcct.GetMessage(Groupwise.ItemMessageIDFromView())
On Error Goto 0
End Ifmsgbox “s3”
If IsObject(oMsg) Then
msgbox “s4”
< code within the loop isn’t relevant at this point >
End If
—
My applet is triggered by the Groupwise application level event of ItemRead
The event fires twice.
The first time I get messages for S1, S2, S3 and no error. I don’t get S4 but I know why.
The second time I get messages for S1, S2 and then the error message.
A few extra message boxes seems to indicate the problem is with this part of the code …
On Error Resume Next
Set oMsg = Client.ClientState.CommandMessage
On Error Goto 0Specifically the “Set oMsg = Client.ClientState.CommandMessage” call
Am at a bit of a loss in how to code around this. I don’t really want the second call to fire at all, especially since it then crashes!
This problem only occurs on my PC (where Creator is) and only for emails in Shared folders so I can live with it but I suspect it leads to the Catastrophic Failure message eventually.
I’ll experiment a little more and see if I can get around it.
Thanks for your help so far
Simon
Hi
I would still like an answer on this. I have delayed releasing 2.1 because of it and that may well be causing some other issues I am seeing (I have just posted under the ‘Creating Solutions’ forum with an issue relating to an Access Violation).
One thing I have discovered with our version 2.0 installation is that some users are not getting a certain key under the Groupwise client. This seems to prevent Formativ from ‘seeing’ Groupwise events.
Re-installing Formativ fixes the problem for that user but not all (even though we have set the flag as described above).
The key I am now adding to a user’s registry is …
HKEY_CURRENT_USERSoftwareNOVELLGroupwiseClientThird Party
The value called “DLL1” is set to “C:PROGRA~1AdvansysFormativTokenBlocker.dll”
This causes the applets to be able to interact with Groupwise for that user as far as I can tell.
Since the key is in the CURRENT_USER hive it has to be done at start-up as respond to who logs in. I’d prefer to not have to do this if I can.
I also need to know that this approach is an OK thing to do at all
Can you explain how the “All Users” part of the installation is meant to work. As far as I know there is no “All Users” part of the Registry and you can’t access each user’s CURRENT_USER hive whilst they are not logged in?
There is a “Default user” which I assume is used to build any new user profiles but I need the installation of 2.1 (or 2.0) to work for any existing profiles.
I am now wondering if 2.0 did the ‘All users’ installation properly. It got tested but possibly it didn’t do any existing profiles and we just happened to use ‘fresh’ logins with our test?
Thanks
Simon
Thanks for the replies. In a way its good to know its not a known problem. I realised it was unlikely to be a Formativ error but felt I should ask.
We are on Groupwise 6.5 SP3 btw. I shall just avoid deleting Field Definitions in the future and hope that it did indeed cause the problem.
Thanks
Simon
-
AuthorReplies