JK-IDE Version 2.0 including Visual Designer V 1.0

[Juergen Kuehlwein]

I'm thinking that [+] should be limited to TAB area only.

the mouse is captured on WM_LButtondown (inside a tab) followed by a WM_Mousemove exceeding an amount of pixels given by getsystemmetrics(%SM_CXDRAG / %SM_CYDRAG). While the mouse is captured, the mouse pointer shows the current status: cannot drag (the red square), can drag left/right or scroll left/right as long as you hold the left mouse button down. This ends when you release the left mouse button (WM_LButtonup) and the mouse pointer changes back to beam or pointer shape.

Limiting the drag action to the TAB area, could be annoying, because as soon as you leave the TAB area the action gets cancelled. That means, you must move your mouse very carefully not to coincidentially spoil dragging. I could limit it to a "reasonable" area around the TAB control, but this isn´t standard behavior. Standard behavior is stopping/finishing a drag action by releasing the left mouse button - no matter where.

Currently i have no explanation for it, and i didn´t change the corresponding code (dragging tabs) for quite some time.

The [+] no drop pointer is obviously misinformed as to its actual location.

Does that mean, it jumps, when it appears - or does it still correspond to the actual mouse position. If your mouse is set to be very sensitive (a slight move moves the pointer more pixels than your current drag threshold) you might very easily get into drag mode inadvertently when just activating a tab. If your left mouse button fails to send a WM_Lbuttonup, or if it sends a repeated WM_Lbuttondown because of a malfunction, you get what you describe.

What about testing with a different mouse ?


JK

[Jim Fritts]

It just appears and corresponds to the actual mouse location. I will try uninstalling the mouse. Reinstalled but untested. The actions that I have described above copy cut paste to include files is new to me so I cannot say if the behavior is indicative of this IDE version or all of them. Note of interest is that I can move the mouse pointer away from the IDE and back to the IDE and the mouse pointer will change back to [+] no drag/drop. That is why I think the IDE should enforce a limit to the drag/drop area even if the User is still holding down the mouse button. It just makes good sense to cancel the drag operation based on the mouse location similar to the way the OK to drop is done. After all, we are not dragging and dropping the dialog so if the pointer gets outside the TAB area then the drag operation makes little sense.

Just tested the reinstalled mouse.

This time without copy cut paste. I think I see the problem. The .INC TABs are behind the TAB scroll direction buttons so when the TAB scroll left is clicked it appears the click is also going below the TAB scroll button and being received by the .INC TAB as a click and hold on that .INC TAB.

May need to replace any TABs that populate behind the TAB scroll buttons with a no TAB/ no drag area.

Note: This is my first experience using the TAB scroll buttons and having more TABs than can fit on the screen. Perhaps this behavior has been lurking in the background all along.

Aw... I widened the IDE size so the TAB scroll buttons are no long encroaching on the .INC TABs. I'll be testing to see if that makes a difference.

[Juergen Kuehlwein]

Jim,


My fist thought when re-testing was: could it be that the WM_LButtondown is passed to the TAB control when clicking a scroll button (an Updown control)? According to Windows standards this shouldn´t be the case, because the Updown control processes this message and therefore should eat it (prevent it from being passed up the parent chain) - but you never know. All i can say, for me this is not the case, WM_LButtondown never reaches the TAB control when a scroll button is clicked.

Could you please drop me a mail at <jk-ide at t minus dot de> so i can return a special test version for you verifying what happens on your computer.


JK

[Jim Fritts]

Juergen,

As yet I have not had any issues since I widened the IDE. The e-mail was sent. It appears the errant behavior happens when the UpDown controls are covering a TAB control and the mouse pointer is leaving or approaching the TAB controls.

See e-mail for specifics.

When the .INC file tab is partially covered by the Up/Down control and I click on the TAB for the file I only get a tab down.

I have validated this behavior many times now. You don't notice it until you get the mouse pointer close to the TAB control again. At that point the mouse pointer changes to [+].

Note: The described behavior only applies to the last TAB in the TAB control.

[Juergen Kuehlwein]

Hi all,


V 2.3.0.9 is online, this fixes a rare problem with unwanted tab drag mode, when activating the rightmost tab - thanks Jim for reporting and helping to fix it!


JK

[Juergen Kuehlwein]

I´m going to be offline because of a vacation. Please don´t expect an answer to your posts within the next 3 weeks or so.


JK

[Jerry Wilson]

I'm probably missing something obvious but does anyone know how to get JK-IDE to run an application in a specific directory? This would be similar to the /D switch in the START command in a Windows Command Prompt window. Even though JK-IDE compiles and correctly places the application in the directory specified by the PB #COMPILE directive, JK-IDE seems to run the application from the directory where the source code is located.

[Dale Yarker]

Is there a copy of the .exe file in the source code directory?

[Jerry Wilson]

No. The source code for the project lives on a NAS but I need to run the application on a local drive for testing. I started out using the PBCC IDE which does seem to use the path in the #COMPILE directive as the starting path to run the application in.This isn't a show stopper. I can use a Command Prompt window to start the application or even create a real simple PBWin app with a button. I'm just lazy

[Dale Yarker]

From post 107 -

JK-IDE seems to run the application from the directory where the source code is located.

If there is no EXE of the compiled program in the source code directory, then it is not being run from there.

Unless JK-IDE is interpreting the source code itself and not compiling (and not causing the compiler result to run.)

[Jerry Wilson]

JK-IDE does compile correctly and place the EXE in the path specified in the #COMPILE directive. So, in this case, the source code is in one directory and the EXE is in another.

Here's some really simple (and useless) code. In my environment, the source code is in a redirected drive x:\dev\projects\sml. The compiled code is saved ONLY in a local directory c:\dev. I used the PB CURDIR$ function to determine what directory the EXE was started in - which I believe is correct. If I compile and run from the PBCC IDE, CURDIR$ returns c:\dev - which is what I need. if I compile and run from the JK-IDE IDE, then CURDIR$ returns x:\dev\projects\sml.

#COMPILE EXE "c:/dev/MyApp.exe"

FUNCTION PBMAIN AS LONG
  PRINT "CURDIR$ = <" CURDIR$ ">"
  WAITKEY$
END FUNCTION

[Dave Biggs]

Seems that the IDE is setting the default directory path to the project/source folder - don't know if there is a user option to control that.

If the current directory is important to your App then maybe you could include something like this in it's source.

If CURDIR$ <> Exe.Path$ THEN CHDIR Exe.Path$

[Jerry Wilson]

I dug around in all of the configuration dialogs and couldn't find a setting either. Perhaps, there may be a switch in a future version (e.g. Run in EXE Path).

Knowing the current directory is important for the app (location of config files and constructing encryption keys) - and that directory is determined by where the customer installs it. For development, I always know where the compiled app is located so I can just use CHDIR at startup to force that - and pull that line for prod release. Thanks for jogging my memory.

[Juergen Kuehlwein]

Hi Jerry,

in fact currently the IDE doesn´t set the current directory for an .exe it runs. It implements the "SHELL" command, which sets the actual current dirctory as new current directory for the new process it starts. That is, in your case the current directory is not the path of your .exe!

I could change that, so that the current directory defaults to the .exe´s path.

On the other side relying on the current directory (CURDIR$) is potentially dangerous, because even if the current directory is process specific, there might be actions inadvertently changing it (among others e.g. Open- or SaveFile Dialog). So in my view you should ALWAYS use exe.path$ for referencing the .exe´s path.


JK

[Jerry Wilson]

Thanks for getting back to me. For development, I need to run the compiled exe in a specific directory (different from source code) but have a workaround to do that - which works fine.

Within the app, I do use EXE.Path$ to determine the current path (you know that I'm trying to clean up legacy syntax in my code). But, I hadn't considered the potential problems with CURDUR$ that you mentioned. Thanks for the advice.

[Juergen Kuehlwein]

Hi all,


V 2.3.0.10 is online - adds a context menu to file tabs, fixes a few issues reported by various users, almost all features now support code inside the (implicit) Main function in FreeBASIC (all code outside procedures), a debugger is under construction. PLEASE DON´T USE THE DEBUG MENU in FreeBASIC, because currently this is likely to crash the IDE.


JK

[Jim Fritts]

Juergen Hi,
No problems to report. Thank you for your hard work.
I just have an annoyance I've been meaning to run by you. As usual I've been doing Find and Replace quite a bit and would like to cut down on my mouse movement to perform that tedious task. I use the JK-IDE at the side of my screen and it would be nice if I didn't have to move my mouse so much. The Replace Dialog saying "No more matches found. Continue searching from the top? Yes No Cancel" only appears at the center of the screen. It would save me a whole lot of time if that dialog was centered on JK-IDE.
Another method would be to add the functionality to the current Find and Replace Dialog and remove the Replace dialog altogether. Just an Idea. Thanks

[Juergen Kuehlwein]

Hi Jim,


why would you want to do Find and Replace one by one? There are three buttons at the bottom of the dialog offering different scopes for this operation. The leftmost button lets you define the scope by a selection, so if you want Find and Replace to occur only in a specific area, select it and use this button - all occurences of "find what" will be replaced by "replace with" in one go.

The more, the second dialog is in fact a messagebox, you could use the keyboard for handling it too.


In general Windows centers messageboxes on the screen, but of course, i could make IDE related messageboxes appear centered on the IDE - this seems to make sense. Let me know, if you still want it centered on the IDE.


JK

[Jim Fritts]

Juergen Thanks for the quick response,

Yes, centered on the IDE would be ideal.
Yes, the different scope buttons are nice for those that can guaranty that what is being replaced is correct (hint: those that live in a perfect world ha ha). Due to similar value spellings I have to validate each change. That is why I don't use the scope buttons all that much. Old school I guess.
Thanks

Note:
The apps I design usually drop a message box / option box at the center of the app or use a text message area on the app to notify the user what is happening. I consider that as courteous to the user. My system is typically just one small display so it's really not that big of a deal; however, I would think those that have much larger screens may feel some pain. I'm just saying...

Aw the escape button... you're trying to get me to do more work aren't you?

[Juergen Kuehlwein]

Hi all,


V 2.3.0.11 is online, this meets Jim´s proposal - all message boxes pop up in the center of the IDE´s main window instead of the Windows default location.


JK