In short.....

Snippet

this.Page.Request.QueryString["_name"].ToString()

Every form is actually a call to form.aspx with a query string parameter (_name). You don't see this in the browser due to the magic of URL rewriting.  

Hope this helps.

S.

This also applies to views which is view.aspx when they are opened indepent of a form and also as a subView I believe.

Scott,

I'm aware of that method, but I didn't want to pull this from url.

For example, if a form is launched as a sub-form, then you have to pull this from the _ID value.

Runtime/Runtime/Form.aspx?_ID=cff27ec9-8d74-44e5-83aa-c52eea13bc39

While it is very trivial to check both of these properties and pick the which-ever it populated, it still is two places to check.  And while I don't think K2 will change their URL scheme anytime soon, they may add some other variant that would cause the code to break.  Thus, I was hopeing for a way to pull this from some runtime api.

Scott, you seem to be the have several of these un-documented api's in your back pocket so I was hopping you would just pull this right out ;-)

Nathan

I can poke around some more, but that is how I solved for it in my own control. Yes you are correct in your assertion that K2 may make changes, but that should be a given and regression testing should be apart of your upgrade strategy.

The challenge in this scenario is that the custom control is really just an inherited concept from a standard .NET web control and things like form name or ID don't trickle down into the rendering page's object model from what I have been able to see. I have found that the form name is placed in the page's title tag, but that isn't exposed in the page object as I get the title for the parent rendering page not the actual form.

I have my own control project where I am exposing this so it will be good to look at further when I can get time to focus on that control again. 

This concept of ID or Name switching is prevalent through the API and in other efforts where I was writing a forms documentation tool I just had to account for both possible scenarios with over loaded methods for the eventuality the key was an ID or a Name.

It would look something like...

var id = identifier.ToString();
if (Type.GetTypeCode(identifier.GetType()) == TypeCode.String)
return fc.GetForm((string)identifier);
else
return fc.GetForm((Guid)identifier);

In your case since it will always be a string and you cannot rely on type, you might try Guid.TryParse and if that fails assume it is a form name but then again if you know it was an _ID or _NAME query string I suppose you don't need to do that.  What I get for typing a stream of consciousness. 

Sorry I don't have better information. Just at this point in the form life cycle we are back down to plain ol' .NET and Javascript having left the SourceCode.Forms.Client API behind at page render.

S.

Thanks Scott!

Feels better to know that others have come to the same conclusions.

In Javascript you would:

var theFormName = $('head>title').text().trim();