投稿者: TAICHI

Nintex Formsでフォームを作成すると、添付ファイルのところに「Dropbox 削除」って出てくるんです。

▼編集画面の添付ファイルコントロール

▼添付ファイルをアップした後の表示

「え？Dropbox？？Dropboxと連携でもするの？？デフォルトで？？」

って思っちゃうじゃないですか。「Dropbox」って言ったらオンラインストレージサービスのDropboxが有名じゃないですか。

これややこしいですね。Dropboxと連携する機能はNintex Workflowにはあるようですが（詳しくないです）、ここに関しては別に連携しているわけではないんですよね。ただのリストの添付ファイルなんですよね。

添付ファイルの他にも出てきます。Formsの編集画面でコントロールを選択した際のリボンを見ると…

出た！Dropbox 削除！
これは結局、コントロールを削除するメニューなんですよね。

ちなみに英語版はどうなっているのかな？とググってみると…「添付ファイルを追加」は「Add Attachment」、「Dropbox 削除」は「Delete」でした。

添付ファイルの削除だけでなく、コントロールの削除にもDropboxが出てくるところを見ると、Deleteを日本語訳した際に「Dropbox 削除」になったんでしょうかね。

Dropboxはいったいどこから出てきたんだ…、謎です。ややこしいので正直「Dropbox」という表記は表示させたくないですね。Formsの編集画面のリボンの方はイイとしても、添付ファイルの部分に関してはユーザーが見る部分なので。JSで消せそうだし、CSSでも消せそうなので、そのうちやってみようと思います。

今回はとりあえず問題提起。もしDropboxに意味があるなどご存知の方はご一報いただければと思います。

Nintex FormsはGUIでグリグリ操作できるのは便利ですが、クセがすごい！（千鳥のマネじゃないです）。でも、クセを把握した上でコツさえ掴めば大丈夫です。

その1として、コントロールをキレイに配置した後に、コントロールの大きさを調整したい場合、該当コントロールを選択し、ドラッグしてマウスを動かすと、なぜか隣のコントロールの大きさが変わってしまう事がある件について。

これはコントロールの重なり順に関係してくるようです。コントロールは一応レイヤーの概念があり、PowerPointの「オブジェクトの順序」みたいなもので、コントロールの配置順に重なっていくイメージです。（厄介なのは最前面と最背面しかない事ですが。）

▼コントロールがキレイに配置されている場合。
▼コントロールを全て選択すると重なり具合がわかります。

隣接されたコントロールが重なると、この上になっている方を優先して掴むようです。（というより掴める範囲が上になっている方が広いという表現の方が正しいです。）

今置いてるカーソルの位置で掴んだらどちらのコントロールが掴めるかの判定は、カーソルを置いて1秒程度で表示されるコントロールの説明ダイアログで判定してください。

厄介なのは一旦操作したいコントロールを選択した上で、サイズを変える□を掴んだとしても、やはり上になっている隣のコントロールを掴んでしまうんです。

▼「body」というラベルを左寄せのまま横幅を狭めたい場合、ラベルを選択し、右の□を掴もうとします。（すでに説明ダイアログには「複数行テキストボックス」と表示されてしまっていますので、この後の挙動は推測できてしまいますが…）

▼案の定、右隣の複数行テキストボックスコントロールが左に広がってしまい、意図した操作ができません。

じゃ、どうしたら良いのか？
1px単位の細かさでマウスを動かして良さげな場所で掴めば意図したコントロールの□を掴めますが、正直ダルいです。

▼ブラウザを200%くらいに拡大すると、ギリギリの場所を掴むのに少しは楽になります。

▼他の方法としては、コントロールを選択して、下矢印キー（↓）などで少しズラす。そうすると隣のコントロールの□と重ならないので掴めます。リサイズした後に元の場所に戻せばOKです。

こんな感じで結構イラっとくる事が多いのですが、挙動を把握した上で、コツさえ掴めば楽しくデザインできます。たぶん…

Nintexの中でもFormsは若干マニアックなようなので、果たしてFormsの記事のニーズはあるかどうか疑問ではありますが、実際自分で試行錯誤している中でググっても特に日本語の情報が薄いので、同様に困っている後発の方々のお役に少しでも立てたらと思います。

前回、コントロールがdivでパズル状態であるという説明をしましたが、もう少しその仕様を掘り下げてみます。

まず、カスタムリストに何も手を加えずにFormsを起動し、タイトル列のラベルとコントロールのみを残し、他を全て削除してみます。

これで一番シンプルな構成になったので解析開始。

とりあえずIEの開発者ツールを見ます（個人的にはFireFoxのFirebugの方が好きなのですが…）。SharePointあるあるですが、シンプルなデザインなのに中身は超入れ子状態のdivを展開しながら色々観察すると、nf-ではじまるclassがあり、なんとなくここからNintexのターンだなと感じてきます。そこから更に入れ子が激しいのですが、把握するためにも1つずつ展開させていき、最終的にtdが1つしかないtableに出会います。

↑このtdの次のdiv class=”nf-outer ms-formbody”がFormsの大枠にあたり、インラインでposition:relative;が記述されています。なので、この左上の位置がコントロールの基点ですね。

↑次にラベルです。このスクショでは見切れてしまっていますが、このコントロールの枠のdivにはclass「.nf-filler-control」があって、これにposition:absolute;が記述されています。で、インラインでtopとleftが指定されており、このラベルは基点に置いてあるのでtop:0;left:0;です。

↑次にタイトル列のコントロール。ここに先ほど見切れていた「.nf-filler-control」の記述がありましたね。position:absolute;が記述されています。で、基点からの位置でtop:0px;left:200px;が指定されています。ラベルではwidth:200px;が記述されていたので、キレイに並ぶという感じです。

こういう仕組みで基点からtopとleftで位置を指定して、パズルが組みあがるという仕様です。

ちなみにコントロールの枠のdivから実際のinputタグの間に更に3個ものdivがありました。
見た目はシンプルなように見えても、中身は複雑で読み解くのが面倒ですね。

しかし、SharePoint自体のデザインカスタマイズでもそうですが、この見た目シンプルでも中身は複雑である事は逆手にとることもでき、CSSのみのデザインカスタマイズをおこなう際に、セレクタを駆使すれば難易度は高いけど自由度が意外と高くなったりしますね。ほら、僕はゴリゴリのカスタマイズや開発は基本的には反対派なので。