gmane.comp.openoffice.devel.framework

[framework-dev] new Apache OpenOffice.org mail list to replace this list

2011-11-02T16:23:59

[framework-dev]

cisca van der merwe — 2011-09-14T15:01:06

How exactly does it work and what must i do to earn money online without
have to pay extra money,cause already paid my fee at the datagroup.
thanx
cisca
Hope to hear soon from u

[framework-dev] Re: ODF 1.2 encryption in OOo 3.4

Mikhail Voytenko — 2011-04-26T11:05:07

Sorry, there was a typo.

On 04/26/2011 01:00 PM, Mikhail Voytenko wrote:

Should be:
In case an original ODF1.2 document created by OOo3.4 contains an 
encrypted library, the library would be encrypted with AES algorithm.

[framework-dev] Re: ODF 1.2 encryption in OOo 3.4

Mikhail Voytenko — 2011-04-26T11:00:48

Hi Bernard, Malte,

As Malte has correctly written, normally the basic library should be 
encrypted using the algorithm, that is used by document ( at least a 
library with known password should be stored in this way ).

There is a special case, when a document with existing encrypted basic 
library is stored with another encryption algorithm. If the library 
still was not decrypted at this point, the target document would contain 
the basic library encrypted with an original algorithm. In other words, 
the encrypted stream is transferred from original document to the target 
one without decryption.

The reason for this decision was that we could not introduce a new UI 
for OOo3.4 at those time. So there were following possible solutions: 
either transfer the encrypted stream to the target document as it is 
done now, or throw it away. The last solution looked not nice ( although 
quite legal, especially when storing from ODF1.2 to ODF1.1 format ), so 
the first one was taken.

Thinking about it one more time, there looks to be an open question. In 
case an original OOo3.2 document created by OOo3.4 contains an encrypted 
library, the library would be encrypted with AES algorithm. If later 
this document is stored in ODF1.1 format without providing the password 
to the encrypted library, the result document would contain a stream 
encrypted with AES algorithm. It would not be possible to decrypt the 
stream using OOo3.3, although OOo3.4 would of course have no problem.

Hope that helps.

Best regards,
Mikhail.

On 04/23/2011 02:18 PM, Malte Timmermann wrote:

[framework-dev] Re: ODF 1.2 encryption in OOo 3.4

Bernard Marcelly — 2011-04-24T07:39:43

Hi Malte,
Thank you for this clarification.
    Bernard

Message de Malte Timmermann  date 2011-04-23 14:18 :

[framework-dev] Re: ODF 1.2 encryption in OOo 3.4

Malte Timmermann — 2011-04-23T12:18:24

Hi Bernard,

all streams in an ODF package are encrypted with the same algorithms /
same implementation. So yes, same for macros.

You can check the used algorithm by looking into manfifest.xml, see
algorithm-name.

Malte.

Bernard Marcelly wrote, On 22.04.2011 14:07:

[framework-dev] ODF 1.2 encryption in OOo 3.4

Bernard Marcelly — 2011-04-22T12:07:14

Hi,

I read this message :
<http://blogs.sun.com/GullFOSS/entry/aes_encryption_for_openoffice_org>
and then :
[allfeatures] changed/cws mav60 : Improve ODF1.2 encryption supporte in OOo.
<http://openoffice.org/projects/www/lists/allfeatures/archive/2011-03/message/2>

Does it also apply to the encryption method for password-protected Basic libraries ?
Answer may be obvious for the designer, but it should be clearly indicated.
Issue 117562 does not test this aspect, also.

Regards
   Bernard

[framework-dev] Re: dispatch framework not respected in calc for inserting new sheet

Mathias Bauer — 2011-04-15T15:39:24

I assume that the problem is not that Calc uses SlotIds, they will be 
converted internally before the call is passed to the dispatch framework.

Most probably the command can't be intercepted because it is executed 
through the SfxDispatcher and not through the SfxBindings. The latter 
forwards calls to the dispatch framework while the former is the 
implementation provider for the dispatch provider that is called by the 
dispatch framework.

Regards,
Mathias

[framework-dev] Re: dispatch framework not respected in calc for inserting new sheet

Laurent Godard — 2011-04-15T08:20:11

Hi again

issue is https://openoffice.org/bugzilla/show_bug.cgi?id=117862

i also gave the URL of the thread
http://comments.gmane.org/gmane.comp.openoffice.devel.framework/274

And for my specific problem ? any hint ? is there an other way to
disable commands like inserting sheets in calc through api ?


Laurent

[framework-dev] Re: dispatch framework not respected in calc for inserting new sheet

Laurent Godard — 2011-04-15T07:54:28

Hi

thanks a lot for your response


ok


right Bernard ;) too quick

< at >carsten
i'll open an issue this morning

Laurent

[framework-dev] Re: dispatch framework not respected in calc for inserting new sheet

Carsten Driesner — 2011-04-15T07:43:33

Hi Laurent,

Bernard is totally right. The dispatch framework uses command-URLs to 
check for disabled commands. Slot-commands are still supported for 
execution but deprecated. I wasn't aware that the calc application still 
use slot IDs for some of their special UI elements. Please write an 
issue for this and set myself as the owner (cd). It makes sense to 
enhance the framework code to support slot-commands, too.

Best Regards
Carsten

[framework-dev] Re: dispatch framework not respected in calc for inserting new sheet

Bernard Marcelly — 2011-04-15T07:24:05

Hi Laurent,
Disable Commands works with mnemonic commands, but not with slot id.

I sent a dispatch with url "slot:26269" and it is still accepted. I suppose that 
in your case Calc still sends a slot id.

Note that your macro should read : "do you want to ENABLE ..."  ;-)

    Bernard


Message de Laurent Godard  date 2011-04-14 16:20 :

[framework-dev] dispatch framework not respected in calc for inserting new sheet

Laurent Godard — 2011-04-14T14:20:12

Hi all

the whole suite menus/action use dispatch framework

this is useful when one want to disable some UI commands by code (eg.
for extension developers)

http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/WritingUNO/Disable_Commands

especially, it is said :
The dispatch framework works with the design pattern chain of
responsibility
...
The disable commands implementation is the first chain member and can
therefore work as a wall for all disabled commands. They are not be sent
to the next chain member, and disappear.

applying this to "Insert" command works for menu entries (insert > sheet
or right click on a sheet tab) - see given macro code

but, the Insert is still available by clicking empty space near sheet tabs

--> these functionality should respect the dispatch framework

it sounds a bug to me.

any idea on how to avoid this ?

Thanks in advance

Laurent

'------------

the macro to test this - answer yes/No wether you want to disable/enable the
Insert sheet command

'---------------------------

dim conf

sub testDisableInsert

conf = getConfigSetting("/org.openoffice.Office.Commands/Execute/Disabled"
,true)

    message = "do you want to DISABLE ""insert sheet"" command ?"
    response = msgBox(message, 32 + 4, "Question")
    value = (response = 6)

    setEnable(value,"Insert")

end sub


sub setEnable(state,url)

    if state then
        enable(url)
    else
        disable(url)
    endif
    conf.commitChanges()
end sub

sub disable(url)

    spliter = split(url,"?")
    nom = spliter(0)
    if not conf.hasByName(nom) then
        elem = conf.createInstanceWithArguments(array())
        elem.setPropertyValue("Command",url)
        conf.insertByName(nom,elem)
    endif

end sub
sub enable(url)

    spliter = split(url,"?")
    nom = spliter(0)
    if conf.hasByName(nom) then
        conf.removeByName(nom)
    endif

end sub

function getConfigSetting(target as string, forUpdate as boolean)
' retourne le noeud de config demandé
' exemple: aSettings = getConfigSetting(
"/org.openoffice.Office.Common/Path/Current", false)

    dim service as String ' nom du service d'acces à la configuration
    dim aSettings, aConfigProvider
    dim aParams(0) As new com.sun.star.beans.PropertyValue
    dim varEmpty

    if forUpdate then
        service = "com.sun.star.configuration.ConfigurationUpdateAccess"
    else
        service = "com.sun.star.configuration.ConfigurationAccess"
    endif

    aConfigProvider = createUnoService(
"com.sun.star.configuration.ConfigurationProvider" )
    aParams(0).Name = "nodepath"
    aParams(0).Value = target

    aSettings = aConfigProvider.createInstanceWithArguments(service,
aParams()
)

    getConfigSetting = aSettings

end function

Re: [framework-dev] Scripting Framework

Carsten Driesner — 2010-11-08T14:27:32

Hi Peter,

Yes, this tip is still correct. We haven't changed the Scripting 
Framework core to optimize the loading of scripts. I don't know if there 
is a plan to do this optimization in the next future. You can contact 
ab-JNqQRFIbOJOM4zKIHC2jIg< at >public.gmane.org directly who is the maintainer of the Scripting Framework.

Regards,
Carsten

[framework-dev] Scripting Framework

Peter Eberlein — 2010-11-08T12:48:18

Hi,

is the following still correct?
Performance: Currently scripts are being loaded by the Scripting 
Framework each time they are run. As such it is important to keep the 
size of your scripts and any dependent jar files they are using 
reasonably small.

 From 
http://framework.openoffice.org/scripting/scriptingf1/developer-guide.html#tips

Regards

Peter

Re: [framework-dev] MacOsX & LayoutManager & macro

Laurent Godard — 2010-10-22T18:45:50

Hi Mathias

thanks a lot for your kind answer

i digged further and came to the conclusion that it was a bug of the mac
os X implementation

using macro modal dialog boxes, the problem still exists.
The document window is locked, but the menu bar remains active

I think this should be adressed because may disturb extensions
developpers (more than disturbing me ;) )

Thanks a lot again

Laurent

Re: [framework-dev] MacOsX & LayoutManager & macro

Mathias Bauer — 2010-10-22T17:26:25

Hi Laurent,

On 13.09.2010 17:01, Laurent Godard wrote:

When I saw your post some weeks ago, I recognized that I couldn't help, 
so I didn't answer and hoped that someone else would step in.

Unfortunately it looks as if noone subscribed to this list can help. My 
gut feeling is that it is not possible to disable the Mac menu bar, but 
that may be wrong. In case an answer would still help you, I can forward 
that to some colleagues that know the Mac better.

Regards,
Mathias

Re: [framework-dev] MacOsX & LayoutManager & macro

Laurent Godard — 2010-10-22T18:45:50

Hi Mathias

thanks a lot for your kind answer

i digged further and came to the conclusion that it was a bug of the mac
os X implementation

using macro modal dialog boxes, the problem still exists.
The document window is locked, but the menu bar remains active

I think this should be adressed because may disturb extensions
developpers (more than disturbing me ;) )

Thanks a lot again

Laurent

Re: [framework-dev] MacOsX & LayoutManager & macro

Mathias Bauer — 2010-10-22T17:26:25

Hi Laurent,

On 13.09.2010 17:01, Laurent Godard wrote:

When I saw your post some weeks ago, I recognized that I couldn't help, 
so I didn't answer and hoped that someone else would step in.

Unfortunately it looks as if noone subscribed to this list can help. My 
gut feeling is that it is not possible to disable the Mac menu bar, but 
that may be wrong. In case an answer would still help you, I can forward 
that to some colleagues that know the Mac better.

Regards,
Mathias

[framework-dev] MacOsX & LayoutManager & macro

Laurent Godard — 2010-09-13T15:01:07

Hi all

i have a macro running and i want to deactivate OOo while it is running,
so that the user can't activate any menu nor click inside the sheet

under windows & linux, it works using
thisComponent.CurrentController.Frame.ContainerWindow.Enable = False

But under macosX, the main menus (File, Edit, ...) are still active

I tried adding
oLayout = ThisComponent.CurrentController.getFrame.LayoutManager
oLayout.HideElement("private:resource/menubar/menubar/")
and it works under linux and  windows, the main menus disappear

But no success under MacOsX i think due to menus detached of the OOo
document window

is there any trick to lock OOo main menu under macOsX ?
(the best would be cross-plateform compatible ;) )

thanks in advance

Laurent

Re: [framework-dev] Framework To-Do's

Mathias Bauer — 2010-09-02T15:29:01

Usually this should have happend in the "bootstrap" step already. It can 
indeed be fixed by explicitly fetching missing tarballs, but I wonder 
what went wrong in your bootstrapping.

Regards,
Mathias