11/26/2024 12:24:17 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Drag and Drop Attachments
Posted: 24 Apr 06 11:55 AM
|
fiogf49gjkf0d I'm writing a replacement attachments tab that uses BLOBs rather than a flat-directory system for storing attachments. Everything is working fine, except for one notable exception...
When a user drags and drops an attachment on top of the sales client, it is added to the system attachment tabs. Is there exposure to this method somewhere so I can trap that attachment and add it to my custom tab instead of the system one? |
|
|
|
Re: Drag and Drop Attachments
Posted: 24 Apr 06 1:00 PM
|
fiogf49gjkf0d I don't think so if you're talking about an in-Architect solution. You would somehow have to trap all drag/drop methods, parse out just the filename drop, and then somehow move it to your custom solution. I believe this is all done at the application level too because if you drag an email, it gets put into history for instance so I think it's different based on exactly what you're dragging and where.
You could probably develop a COM object or a custom app that fires up when SalesLogix does to trap all drag and drop methods. You would then allow everything but an attachment drag and drop but deny that entirely. You would use the data to create the attachment using your routine completely bypassing SalesLogix's internal routine. That's the only way I can see this working but someone else may have a better alternative. |
|
|
|
Re: Drag and Drop Attachments
Posted: 25 Apr 06 9:59 AM
|
cialis generico costo acquistare cialis in farmacia open fiogf49gjkf0d Curious. In 6.2, there is an attachment tab for tickets in the Architect, but not one for the other forms. They must be compiled. The one for ticket attachments has the following functions in it that do not appear to be referenced elsewhere in the attachment view scripts:
Function AXFormFileDragOver(Sender, X, Y)
AXFormFileDragOver = True
End Function
Sub AXFormFileDrop(Sender, FileName, X, Y)
Application.BasicFunctions.InsertFileAttachmentEx FileName
grdAttach.Refresh
End Sub
Think these might have an affect? |
|
|
|
Re: Drag and Drop Attachments
Posted: 26 Apr 06 2:14 PM
|
where to get abortion pill how much is the abortion pill click fiogf49gjkf0d There are DragOver and Drop events for each form, so it looks like the attachment tab for Tickets is using those events to call the appropriate InsertFileAttachment function. The attachment tab for every other section is hardcoded so there is no way currently to override their events without the suggestions I provided earlier.
You could always try turning the tabs off but as mentioned in another forum, users can be resourceful enough to turn them back on. You can use this knowledge to add DragOver and Drop events to your custom forms which should be done but I don't think it will override the current behavior at all so you may be back to square one. Since you don't have to have the attachment tab open for the drop event to attach the file, it appears as if the method is application-specific or outside of just one particular tab.
You're left with at least these 2 scenarios:
1) Make a drop monitor app that monitors the clipboard for any file or drag/drop operation being done on SalesLogix and halts it. I know all of the information is copied to the clipboard so you could probably halt it there but I wouldn't know how to proceed personally.
2) Make a attachment monitor that looks for standard attachments and converts them into the BLOB attachments you normally use. I would think this would be easier personally but if you have remotes, attachments are going to be a hassle to manage in this scenario as you may have the attachment at one or both ends before it can get processed correctly.
There may be another solution out there I can't think of that would be easier to deal with. Either method seems like a lot of work for very little pay-off. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|