InfoPath - GetUserProfileByName - Get user information on another person

You can obtain the functionality by using the webservice called: userprofileservice.asmx. Take a look at this guide:
http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx?

This guide does not have an example of how to get user information on another person. You can do this by:

• Adding a field
• Adding a button
• Actions for the button:

1. Set field value: GetUserProfileByName:myfields:QueryFields:AccountName = The field you added in step 1
   
2. Recieve data with GetUserProfileByName
   
3. Now you have populated the GetUserProfileByName with all the data on the new user from the SharePoint user profile database.
   
4. Perform step 1 to 11 followng the guide in the link above to fill out fields of your choice

Tip of the day: The above mentioned method will leave you with a very rigid input field to get info on a new user. To solve this problem you can use the contact selector. Google: "InfoPath Contact Selector".

Done :-)
If this is making no sense at all let me know.
Best regards

REF: http://www.infopathdev.com/forums/p/7844/29319.aspx#29319

SP - User web services you can call

http://Server_Name/_vti_bin/UserGroup.asmx


_vti_bin/UserGroup.asmx


Need to learn more, post for ref

Using InfoPath 2007 Translate function to do what XPath lower-case function does

REF: http://blog.michaellotter.com/post/0a09090909-Using-InfoPath-2007-Translate-function-to-do-what-XPath-lower-case-function-does0a-0a090909.aspx

Several days ago Joe and I found ourselves wanting to make sure we made the InfoPath “UserName()” function return all lower case characters and we decided to use the common XPath function “lower-case” but was surprised because it didn’t work. With a little research I found that we could use the InfoPath “Translate” function instead. I must say that it’s a little frustrating that some common XPath functions don’t work and you have to find the work around but if you do any InfoPath development you come accustom to it. Below is what we tried that didn’t work and what we did that did work.

What didn’t work:

lower-case(xdUser:get-UserName())

What did work:

translate(InsertFieldHere, "ABCDEFGHIJKLMNOPQRSTUVWYXZ", "abcdefghijklmnopqrstuvwyxz")

Basically for “Translate” we had to specify every letter in the alphabet in UPPERCASE and then lowercase to make sure every character will get translated. For more information on “Translate” checkout this link http://office.microsoft.com/en-us/infopath/HA012330391033.aspx and do a search for “Translate” for the official description (It’s towards the bottom of the page).

If you foresee yourself using this more often then something to consider is creating a “Template Part” for this. It would be very simple because it would have two fields one called “translate_uppercase” and another “translate_lowercase” and each field default value would be the alphabet in the correct case. Then whenever you would want to use the “Translate” function you would add the “Translate Lower Case Template Part” to the form and build the expression as translate(fieldname, translate_uppercase, translate_lowercase). This would be a lot simpler than typing in all those letters and if you have more than one person doing InfoPath development it would create a standard way of doing it.

Syntax

translate(argument1, argument2, argument3)

• argument1 The name of the field that contains the text whose characters will be replaced. Separate arguments with a comma.
  
• argument2 A character or the value of a field with a text data type that will be replaced by the characters in the third argument. Separate arguments with a comma.
  
• argument3 A character or the value of a field with a text data type that will replace every instance of the character in the second argument

Note: This should be used with caution though because it has a significant impact on performance. The translate function is SOOOO much more demanding than the lower-case function.

Forcing InfoPath form links to load in web browser

by: dougthebuilde (formerly bobthebuilder)

REF: http://suguk.org/blogs/sharepointhack/archive/2007/05/06/3281.aspx

Scenario and solution:
You have a page that containd web part views into your forms library (that contains forms that can be filled out in a browser). The problem here is that if you or your client has InfoPath installed on their computer, everytime they click the link the form will try and open in their InfoPath client; prompting them for authentication.

If the client goes to the forms library itself and clicks on a InfoPath form the form opens in the browser no problem, why? The answer is in the url, try this:

• Go to the forms libray and click on a form, check the URL; it should look something like this:
  
  http://site.example.com/subsite/_layouts/FormServer.aspx?XmlLocation=/subsite/formLibrary/formName.xml&Source=http%3A%2F%2Fsite%2Eexample%2Ecom%2Fsubsite%2FformLibrary%2FForms%2FMyView%2Easpx&DefaultItemOpen=1
  
  
• Now go the web part and click the same form, check the URL (in the browser status bar): http://site.example.com/subsite/formLibrary/formName.xml
  
• Note that the URL is completely different which is why I think the form does not want to open in the web browser view.

Now, to fix the URL in the web part we are going to need to convert that web part to a data view web part through sharepoint designer:

• Open one of your forms from the form library and copy the URL into NotePad.
• Open the offending page containing the web part in sharepoint designer.
• Go to design view, right click the web part and select convert to xslt data view.
• Select the ">" next to the data field that you want displayed as the link to the file and then select the option to format the text as a hyperlink.
• In the new dialog box, in the location text box paste the URL from NotePad.
• Replace the following text: "XmlLocation=/subsite/formLibrary/formName.xml" in the location text box with "mailto:XmlLocation=%7B@FileRef%7D" this tag indicated the full URL to the form.
• Save

Open the web part page and click the link in the web part: the form now opens in a web browser!

10 best online color tools

ColorCombos
COLOURlovers
ColorExplorer
Kuler
ColorJack
Sessions.edu
Color Palette Generator
Color Hunter
Color Scheme Generator
Stripe Generator

REF: http://www.downloadsquad.com/2008/10/09/color-me-crazy-10-best-online-color-tools/

People Picker Control for Infopath 2007

Ever wanted to have a people picker kind of control in Infopath form and that too in browser mode. Did i heard yes :) , well there is a Active-X control which takes care of this part named "Contact Selector Control".Just follow the steps to get it working :

Add Contact Selector to Controls Pane

Click the "Add or Remove Controls " from the Control Task pane as shown in figure























Click ADD

Select Active-X

This will display a list of controls , select "Contact Selector" ,click Next

Select "Don't include a .cab file"

From drop down select "Field or Group(any data type) and click finish

DataSource for the Contact Selector control

Add non Repeating group named "group1"

Add a repeating Group names "Person"

Add following test field to the "Perosn " group (DisplayName,AccountId,AccountType)












Add Secondary datasource XMl file with details about the SharePoint Server , this is required by the form in order to validate the user against a particular sharepoint server .

Open Notepad and add the following Tag



Save the file as Context.xml

Add new connection as "Receive Type" and source of data as "XML"

Option “Include the data as a resource file” shoule be enabled























Drag control to the form and you are all set .Best of Luck !!!!
Posted by Raghu Iyer at 9:55 AM
Labels: Infopath 2007


REF: http://metahat.blogspot.com/2007/05/people-picker-control-for-infopath-2007.html

----------------------------------

See Also: http://www.sharepointassist.com/2009/02/27/adding-a-contact-selectorpeople-picker-to-an-infopath-form/

$().SPServices.SPCascadeDropdowns

Function$().SPServices.SPCascadeDropdowns

FunctionalityThe SPCascadeDropdowns function lets you set up cascading dropdowns on SharePoint forms. What this means is that you can enforce hierarchical relationships between column values. The function uses the GetListItems operation of the Lists Web Service to refresh the allowable values based on relationships which are maintained in reference lists. By implementing this function, there are no coding requirements to manage the hierarchical relationships (once it is in place) and you can let your users manage the content in the reference lists.

This function works with any number of options in the dropdowns as well as multi-select parent and child columns, as shown in the following table. This is significant because each of the three column types are rendered significantly differently by SharePoint.

When the relationshipList contains lookup columns for both the relationshipListParentColumn and relationshipListChildColumn columns, the function uses the relationshipListParentColumn's ID rather than the relationshipList item's ID. This means that "secondary lists" are also supported.

Find out more here
REF: http://spservices.codeplex.com/wikipage?title=%24%28%29.SPServices.SPCascadeDropdowns&referringTitle=Documentation