Understanding how Working Preview's simulated login works.

[jwilliamson]

I have been struggling to understand how Working Previews simulated login works, because it would be really swift if I could get it to work properly

Firstly I'm wondering which event should I use this in? OnGridInitialize or OnGridExecute?

Also, what is the scope of the session variable when used in this manner? Do they exist only for the scope of that event or for all subsequent events?

The reason I ask is I have this code in the OnGridInitialize event:

function OnGridInitialize as v (e as p)
	if eval_valid("request.SERVER_PROTOCOL") then 
		if request.SERVER_PROTOCOL = "A5RES" then 
			'running in working preview
			dim session.Userid as c
			dim session.UserType as c	
			session.Userid = "[email protected]"
			session.UserType = "3"
		end if 
end if

But then when I reference session.UserType in the OnSummarySectionRender I get an error:

"Error executing OnSummarySectionRender event handler: command: Case session.UserType = "2" Property not found
session.UserType subelement not found."

If you are curious this select case code works fine when published locally using WAS or IIS.

The bit of code is

Select 
	Case session.UserType = "2"

Just curious what I'm doing wrong here.

[RichCPT]

Re: Under standing how Working Preview's simulated login works.

Are you running an old version of AlphaAnywhere?

The new, defaut sample code for OnGridInitialize looks more like this:

'TIP: To simulate session variables when running in Working Preview you can use this code:
'if eval_valid("request.SERVER_PROTOCOL") then 
'	if request.SERVER_PROTOCOL = "A5RES" then 
'		'running in working preview
'		session.var1 = "simulated value for var1"
'	end if 
'end if

Notice, do not use "dim session.var1 ....". Remove the "dim session ..." lines and see if that works better for you. Having a line like "dim session.var", can end up creating the "session" pointer variable in the wrong scope.
I just used put those debugging lines (but without the "dim session..." lines) into the OnGridExecute and cross my finger that I remember to take them out before publishing.

But, if you use Alpha's sample code above in OnGridInitialize and it still does not work then I would add a third"IF" to like this:

if eval_valid("request.SERVER_PROTOCOL") then 
  if request.SERVER_PROTOCOL = "A5RES" then 
     '--running in working preview
[COLOR="#0000FF"]     if .not. variable_exists("session")
        DIM GLOBAL session as P '-- For debugging, never ever do this in live code
     end if[/COLOR]
     session.var1 = "simulated value for var1"
  end if 
end if

Keep in mind that the OnGridExecute runs BEFORE onGridInitialize. I have know idea why alpha got that event sequence so messed up, but it is unfixable at this point. For UX's they seem to have gotten the event sequence correct and the OnDialogInitialize does run before OnDialogExecute, as one would expect.

It may be that you are doing something with session vars, such that you really do need to initialize them in the onGridExecute, when debugging, instead of onGridInitialize.

[jwilliamson]

Re: Understanding how Working Preview's simulated login works.

Hi Rich,

I'm still getting an error that in the OnSummarySectionRender event even with your added if statement. I've alternated between OnGridInitialize and OnGridExecute with no luck.

Getting the same error:
Error executing OnSummarySectionRender event handler: command: Case session.UserType = "2" Property not found
session.UserType subelement not found. Code works when published though.

Here is what I'm using after following your advice.

	if eval_valid("request.SERVER_PROTOCOL") then 
		if request.SERVER_PROTOCOL = "A5RES" then 
			'running in working preview
			     if .not. variable_exists("session")
	        DIM GLOBAL session as P '-- For debugging, never ever do this in live code
	    end if
			session.Userid = "[email protected]"
			session.UserType = "3"
		end if

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

Argh! Sorry, I was wrong. I debug all the time with session vars, but apparently when things are not step-by-step identical one can never guess what Alpha is going to do. I would move the initializing of the debug session vars to a common xbasic routine that you can call from any of the server-side events that you are attempting to debug. And, for debugging just have all the server-side events that you are using, call that debug routine. I did a little test and I can see that the proper "session" pointer var is not being passed into any of the numerous server-side events I just tested.

[jwilliamson]

Re: Understanding how Working Preview's simulated login works.

Argh! Sorry, I was wrong. I debug all the time with session vars, but apparently when things are not step-by-step identical one can never guess what Alpha is going to do. I would move the initializing of the debug session vars to a common xbasic routine that you can call from any of the server-side events that you are attempting to debug. And, for debugging just have all the server-side events that you are using, call that debug routine. I did a little test and I can see that the proper "session" pointer var is not being passed into any of the numerous server-side events I just tested.

Hey Rich,
I had thought of that too but thought setting and resetting the session variables would somehow mess things up since I didn't know what was going on, but they are variables, they're meant to be changed. I tried it out it crashes OnSummarySectionRender. The loading spinner starts going and doesn't stop. I'm not sure why. I'll mess around with it some more and see if I can figure out what is going on. I know that there are certain things in alpha that behave slightly different published than in working preview.

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

Hey Rich,
.... The loading spinner starts going and doesn't stop... .

Does anyone have a fast way to figure out what has gone wrong when that happens? I know about running the app in a browser and turning on Developer Tools (F12), and looking at the "Console" error messages. But so many times all I get is "Syntax error" and it will be on an "eval()" statement where Alpha has sent back a massive set of JavaScript. If I can squeeze a "debugger;" statement at the top of Alpha's returned string then sometime it helps. If I'm able to get a debugger statement in there before the error than the developer tools "pretty print" function really helps. In Chrome "pretty print" is the "{}" text button on the bottom status bar.

[jwilliamson]

Re: Understanding how Working Preview's simulated login works.

Rich I was able to get this working to some for a lot of my app's functionality. I used your function and for some reason it didn't cause crashes this time. Also of note, is when you have freeform templates you have to set session variables for them as well, but you can't use an xbasic function like "SimulateSessionVars()" because alpha anywhere won't find the function, I guess it's out of scope. So you have to paste the contents of that function into your A5W xbasic code. This isn't too bad if you're system isn't super dynamic and you only have to copy code a few places. In my case I had to copy it into the free form search columns section and my header which displays user information.

The only thing that kinda stinks is that buttons on my app set session variables which aren't remembered between function calls, so i still end up needing to use local preview a lot.

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

...buttons on my app set session variables which aren't remembered between function calls...

I use session vars for data that does not change after the user has made it through the complete login procedure.

It is best to use methods other than session variables when trying to pass dynamic data between the components. See the video help library.

Building off of Video M36, I have uploaded this application to google docs that demonstrates some of the methods that I use. Download the workspace (click "this", over to the left), publish it, and open the "M36_main.a5w" page. You'll have to read through the comments on the a5w pages and in the components to see what it does. It has been quite a while since I looked at my sample; hopefully it still works!

[jwilliamson]

Re: Understanding how Working Preview's simulated login works.

Thanks Rich.

I downloaded the application but none of the buttons worked. I think what you are saying about session variables only used after login makes sense as session implies the value stays the same throughout the session. In my system we have several preset search options that the user can select, which is just a a preset selection of search filters. If a user selects one of these presets we want to hide any summary rows that no longer apply, not just show zero values.

I do this by setting a session variable on the server using an ajaxcallback, this way it is available during the SummarySectionRender event, which is where the JS is actually computed to hide rows. I suppose I could just use a global variable and not a session variable to do this. Maybe a state variable, but I need to look in to what that actually is! : )

The variable being set by the ajaxcallback is defined in the onclick method of each button and passed back to a case statement on the server, but I really should be coming up with an algorithm to handle hiding rows based on the search filters in the AfterSearch function.

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

I've been playing with the app after I uploaded it; it does not work as well as it used to - perhaps there have been changes to Alpha or maybe I just messed things up in it. Some of it still works, though.

There is a difference between running "M36_MAIN.a5w" and "TabbedUI_M36_TabbedUI.a5w". I think the argument passing works better under the tabbedUI example.

Also, if you get errors about fields not found then maybe the system needs to have the ".DDM" files that go along with the two data files. I just added them to the zip file this morning.

The updated zip file is located here

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

A technique I use for conditionally hiding items is to embed flags into the data returned from SQL. This does mean that instead of just having one copy of the flag, I end up with a copy of the flag in every row. So, wasteful, but that seems to be the way to do things sometimes. In my system the flags are embedded in the actual table rows of data, because the values are established at the time a particular set of related records are created, not at a later time.

It seems to me you might be able to add a calculated field expression that returns a flag based on a SQL parameter. I would think having the flag available at the row level would make it easier in setting up the conditional summary rows.

[jwilliamson]

Re: Understanding how Working Preview's simulated login works.

That fixed it. Pretty cool application. I think I could see using something like that in some additions we want to make to our application. I also saw where you were using state variables which was helpful. I was using session variables where I should have been using them for my call backs.

I think you could also set a logical flag in your application when the user submits a search and create an algorithm based on what boolean values are set to hide rows. Like hide all summary rows by default and then if a user selects "Work In Progress" from our milestone dropdown something like this would run:

if bWorkInProgress = .t. then 
js + js = "window.elementById('summary-row').style.visbility='visible';"

or whatever the actual javascript is

[RichCPT]

Re: Understanding how Working Preview's simulated login works.

Yes, adding javascript or jquery commands to set element styles programmatically is something I have to do a lot. Especially for controls in complex updateable grids. This is because Alpha does not let one specify the exact elements the styling needs to be applied to when it comes to compound controls like a textbox with Grid Lookup displayed as a dropdown or a textbox with a Date Lookup.

Another thing to consider, though, is using CSS. If you can either dynamically change the CSS or dynamically change the CSS class name applied to an element then you can achieve dynamic stuff much faster than having to execute javascript against a bunch of elements.