You are not logged in.

  • 1
  • 2

Dani

Intermediate

Posts: 325

Date of registration: Nov 19th 2009

Location: GERMANY

  • Send private message

21

Thursday, September 12th 2013, 2:18pm

Quoted

If I for instance use the App.Path command in a program, and place that program on a flash drive, or any other drive, shouldn't it yield the path to the folder of the operating program?


Strange ... thats exactly what it does for me now!

Jabaco Source

 
1
2
3

Public Sub Form_Load()
Text1.AppendText   App.Path
End Sub


Are you sure you updated your Jabaco.jar correctly?

Dani
latest Jabaco.jar:
Jabaco.jar on bitbucket since other links are down !!
Jabaco Framework source:
https://code.google.com/p/jabacoframework/source/list

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

22

Thursday, September 12th 2013, 4:20pm

RE: App.Path

Quoted from "Perry"

There was one version ( 105 ) where this worked properly. Where was this changed? We might have to go back and study that?
It is all there, in the actual version 111.
The App.Path of version 105 is identical to HomeDir. That will not change, if you move the program. So I don't think, that this is, what you want.
Later there was integrated the code of Dani in App.Path. The problem: With getClass(...) it gets the class where it stands in. In our case, it is the class called App, which is in Jabaco.jar in the Jabaco directory. So I have created later App.JabacoFrameworkPath, which have still this implementation.
The current implementation of App.Path is still in work. But I have currently not the time to implement it correct. And I am fagged of my job.
Currently the App.Path
- showing the right full path, if you start your program in the Jabaco-IDE
- showing the right full path, if you start your program on Windows with a dubble-click on your Jar-file.
- showing on Windows ".\", if you start it on commandline with "java -jar program.jar".
- showing on Windows "myDirectory\". if you start it on the superdirectory with "java -jar myDirectory\program.jar".
- showing full path with the jar-file at the end, when you start it in Windows with "java -cp program.jar Module1".
- showing the right full path, if you unzip the jar-file and start the program with "java Module1".

As I said: In most cases, it works correct. But if you compile it to a jar file, then you can use App.JabacoFrameworkPath. Because if you compile it, the Jabaco Framework will be compiled in the created jar file, so App.Path and App.JabacoFrameworkPath giving out the exacltly same directory.
And because App.Path work currently not in all cases correct, at the moment App.JabacoFrameworkPath will be better for you for compiled programs.

And if you still don't like all current implementations, you can still use

Jabaco Source

 
1

New java#io#File(getClass.getProtectionDomain.getCodeSource.getLocation.toURI.getPath).getAbsolutePath
direct. Or other implementations, which are mentioned here in this thread.

Greatings
theuserbl

Perry

Beginner

  • "Perry" is male
  • "Perry" started this thread

Posts: 40

Date of registration: Jan 15th 2011

Location: Sarasota, FL

Occupation: Cabinet Design

Hobbies: Programming

  • Send private message

23

Thursday, September 12th 2013, 5:06pm

Reply to Dani

To Dani;
Lets see I'm using WinXP
(I downloaded and saved the new jar all over again for this test, just in case I had a currupt jar)

Download Jabaco-rev111.jar from the link in this thread

place it in C:\Program Files\Jabaco\

rename existing Jabaco.jar to JabacoOld.jar

rename Jabaco-rev111.jar to Jabaco.jar

run Jabaco

what am I forgetting?


I Made a Simple Program to test this and Compiled & stored it on My F: Drive
I placed a command button on the form and a textbox

This is the code

Source code

 
1
2
3
4
5
6
7
8
9
10
11

Dim gLP As String

Public Sub Form_Load()
   gLP = App.Path
   
   
End Sub

Public Sub Command1_Click()
   Text1.Text = gLP
End Sub


These are the results from the executable program loaded and run from the F: Drive


C:\DOCUME~1\PERRY~1.ALB\LOCALS~1\Temp


This is the Same program recompiled with jar version 105. It was also placed on the F: Drive



F:\

Userbl
We'll try to work with your changes until you get the bugs worked out.

This post has been edited 2 times, last edit by "Perry" (Sep 12th 2013, 5:37pm)

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

24

Thursday, September 12th 2013, 5:32pm

RE: Reply to Dani

Quoted from "Perry"

C:\DOCUME~1\PERRY~1.ALB\LOCALS~1\Temp


It works perfect. :)

The point is, you compiled not to jar-file. You compiled to an exe-file
And the exe-file extracts the included jar-file in that temp-directory and start the jar-file there. :)

Have a look in
C:\DOCUME~1\PERRY~1.ALB\LOCALS~1\Temp

If your file was called MyProgram.exe, then you will find in this directory the file MyProgram.exe.jar

Greatings
theuserbl

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

25

Thursday, September 12th 2013, 5:50pm

RE: RE: App.Path

Quoted from "theuserbl"

The App.Path of version 105 is identical to HomeDir.
Correction:
The App.Path of version 105 is identical to CurDir.

But do you really think, that CurDir is a better implementation of App.Path then the current App.Path?

You begun this thread, that the old implementation of version 105 don't work correct for you.

Greatings
theuserbl

theuserbl

Intermediate

Posts: 436

Date of registration: Dec 20th 2008

  • Send private message

26

Thursday, September 12th 2013, 6:07pm

Last post from me for today.

Here a little program, which tests all three for you:

Jabaco Source

 
1
2
3
4
5

Public Sub Command1_Click()
   MsgBox "CurDir: " & vbNewLine & CurDir & vbNewLine & vbNewLine & _
        "App.Path: " & vbNewLine & App.Path & vbNewLine & vbNewLine & _
        "App.JabacoFrameworkPath: " & vbNewLine & App.JabacoFrameworkPath
End Sub

Greatings
theuserbl

Perry

Beginner

  • "Perry" is male
  • "Perry" started this thread

Posts: 40

Date of registration: Jan 15th 2011

Location: Sarasota, FL

Occupation: Cabinet Design

Hobbies: Programming

  • Send private message

27

Thursday, September 12th 2013, 7:31pm

Re: theuserbl

If you follow this thread long enough, you will find that initially I had a currupted jar (105), which I reinstalled.
CurrDir actually yields the results I wanted, so I'll use that.

For the most part I'm not so concerned that Jabaco has everything just like VB6 though that would be nice. I just wanted some method of yielding the results that I wanted to see. In VB6 I would have used App.Path. CurrDir does fine.

See I've already programmed that Library Application using App.Path. That worked OK as long as I used (105). But now the source will not work for others, unless they change App.Path to CurrDir if they use subsequent versions of the jar. That's OK as long as folks understand that the jar files are still being updated.

For a program to reside and operate from a flash drive; keeping the data so that it will also reside on the flash drive; so that you can take it with you and plug it into another computer and still have all the data files; and still work properly, you obviously need some command that will locate the directory of the load address of the executable wherever that may be, because it potentially changes from one computer to the next, and never installs on the operating computer, though as you mentioned it may functionally run from a Temp Directory. Though it may run from a Temp Directory it still must locate it's data files which are still on the flash drive.

Whew.... that was longwinded!
Anyhow having said all that...
How it now stands is OK.
  • 1
  • 2

1 user apart from you is browsing this thread:

1 guests

Similar threads

Rate this thread
WoltLab Burning Board